Fin de support des CMS : le calendrier 2026-2027 que votre budget maintenance doit intégrer

Le calendrier des fins de support, d'octobre 2026 à décembre 2027

Quatre échéances structurent les dix-huit prochains mois pour un site web en production : Joomla 5 perd son support correctif le 13 octobre 2026, Drupal 10 atteint sa fin de vie le 9 décembre 2026, PHP 8.2 s'arrête définitivement le 31 décembre 2026, et le règlement européen Cyber Resilience Act devient pleinement applicable le 11 décembre 2027. Aucune de ces dates ne casse un site du jour au lendemain. Toutes changent son profil de risque.

C'est la principale source de malentendu entre une direction générale et son prestataire technique. Une fin de support ne produit pas d'écran noir. Le site continue de répondre, les formulaires continuent d'envoyer des messages, le back-office continue de s'ouvrir. Ce qui s'arrête, c'est le flux de correctifs. À partir du moment où l'éditeur ne publie plus de mise à jour pour votre branche, chaque vulnérabilité découverte reste ouverte sur votre installation, et les bases de données publiques de vulnérabilités indiquent très précisément à qui veut les lire quelles versions sont concernées.

La bonne façon de lire ce calendrier n'est donc pas « quand mon site tombe-t-il en panne », mais « à partir de quand est-ce que je paie pour un risque que je ne maîtrise plus ». Et cette question, contrairement à la première, se traite dans un budget et dans un planning, plusieurs mois à l'avance, au tarif d'une opération planifiée plutôt qu'à celui d'une intervention d'urgence.

Les quatre échéances de la période sont indépendantes les unes des autres sur le papier, mais elles s'enchaînent dans la réalité d'un serveur. La fin de PHP 8.2 impose une montée de version du langage. La montée de version du langage impose que le CMS et ses extensions soient compatibles avec la nouvelle version. Et cette compatibilité, pour Joomla comme pour Drupal, passe très souvent par une montée de version majeure du CMS lui-même. Vous ne choisissez pas ces trois chantiers séparément : vous choisissez l'ordre dans lequel vous les menez.

Joomla 5 perd son support correctif le 13 octobre 2026

Joomla 5 cesse de recevoir des corrections de bugs le 13 octobre 2026 et n'est plus suivi qu'en sécurité seule jusqu'au 12 octobre 2027. Joomla 6.0 est sorti le 14 octobre 2025, Joomla 6.1.0 le 14 avril 2026, et la branche est maintenue en corrections jusqu'au 17 octobre 2028, puis en sécurité seule jusqu'au 16 octobre 2029. Un site Joomla 5 dispose donc d'un an de sursis sécurisé, pas davantage.

La nuance entre « fin du support correctif » et « fin du support de sécurité » compte, et elle est rarement expliquée. Pendant l'année qui sépare le 13 octobre 2026 du 12 octobre 2027, un site Joomla 5 reçoit encore les correctifs de sécurité. En revanche, un bug fonctionnel découvert pendant cette période ne sera pas corrigé sur la branche 5. Si votre éditeur de formulaires, votre module multilingue ou votre composant d'agenda se met à mal se comporter après une mise à jour d'extension, vous n'aurez plus d'autre recours que le contournement manuel ou la montée de version.

Le vrai verrou n'est pas Joomla, c'est le serveur

Joomla 6 a relevé ses prérequis techniques : PHP 8.3.0 au minimum, contre PHP 8.1.0 pour Joomla 5, avec MySQL 8.0.13 ou MariaDB 10.4.0. Les versions officiellement recommandées par le projet sont PHP 8.4, MySQL 8.4 et MariaDB 12. Autrement dit, un hébergement resté sur PHP 8.2 ne peut tout simplement pas accueillir Joomla 6, et la question de l'hébergement se pose avant celle du CMS.

C'est un point à vérifier tout de suite, et il se vérifie en quelques minutes dans le panneau d'administration de Joomla, à la rubrique Système puis Informations système. Si vous y lisez PHP 8.2 et que votre hébergeur ne propose pas au moins PHP 8.3, vous avez deux chantiers au lieu d'un, et le second, le changement d'hébergement, est de loin le plus long à organiser. Nous le constatons régulièrement lors des audits de site web que nous menons avant ce type d'opération : l'obstacle est rarement le CMS, presque toujours l'environnement d'exécution.

Une montée de version, pas une migration

Il faut rendre justice au projet Joomla sur un point : le passage de Joomla 5.4 à Joomla 6.0 est une montée de version, pas une migration au sens où l'était le passage de Joomla 3 à Joomla 4. Les données restent en place, l'arborescence reste en place, les URL restent en place. Le projet fournit de surcroît un plugin « Behaviour - Backward Compatibility 6 » qui permet de faire fonctionner temporairement des extensions écrites pour Joomla 5 dans un environnement Joomla 6.

Ce plugin est une béquille utile, pas une solution. Il vous achète le temps de faire mettre à jour les extensions par leurs éditeurs, ou de les remplacer. Les suppressions de code qui le rendent nécessaire sont connues et documentées : la syntaxe Factory::getApplication()->input disparaît au profit de Factory::getApplication()->getInput(), la constante JPATH_PLATFORM n'existe plus. Ce sont exactement les endroits où un développement spécifique réalisé il y a cinq ans par un prestataire qui n'est plus là va se briser silencieusement.

Le travail réel d'une montée de version Joomla 5 vers 6 se situe donc là : l'inventaire des extensions, la vérification de leur compatibilité annoncée, l'identification des développements sur mesure, et la recette sur une préproduction. Le cœur de Joomla, lui, se met à jour en quelques minutes. Notre page dédiée à la maintenance Joomla détaille la façon dont nous séquençons cet inventaire.

Deux réglages à vérifier avant tout

Deux détails de configuration méritent votre attention immédiate. Le premier est le canal de mise à jour : Joomla en propose trois, Default, Joomla Next et Testing. Un site de production doit rester sur Default, faute de quoi une mise à jour majeure peut être appliquée par inadvertance depuis le back-office, un lundi matin, par une personne qui voulait simplement cliquer sur le bouton vert.

Le second est la mise à jour automatique du cœur, introduite avec Joomla 5.4 et reprise dans Joomla 6.0. Sur un site personnel, c'est un progrès. Sur un site professionnel intégré à un système d'information, une mise à jour appliquée sans préavis et sans recette est un risque, et il est raisonnable de la désactiver pour conserver la maîtrise du calendrier d'intervention.

Drupal 10 s'arrête le 9 décembre 2026, la semaine même où Drupal 12 sort

Drupal 10 atteint sa fin de vie le 9 décembre 2026, dans la semaine où Drupal 12.0.0 est publié. Drupal 10.6.0 est la dernière version mineure de la branche 10. Les branches antérieures sont déjà hors support : Drupal 10.4.x ne reçoit plus rien depuis décembre 2025, et Drupal 10.5.x a perdu son support de sécurité en juin 2026. Un site Drupal 10 doit donc d'abord savoir sur quelle mineure il tourne.

Cette distinction entre versions mineures est la particularité de Drupal, et elle piège beaucoup d'équipes. Dire « nous sommes en Drupal 10 » ne dit rien du niveau de risque. Un site en 10.6 est couvert jusqu'en décembre 2026. Un site en 10.4 est déjà exposé depuis bientôt un an, sans que rien ne le signale visiblement en façade. La vérification prend là encore quelques secondes, via la page Rapports puis Mises à jour disponibles de l'administration Drupal, ou en ligne de commande avec drush status.

Le rythme a changé, et il faut s'y adapter

Drupal a adopté un cycle de versions majeures tous les deux ans, les années paires, chaque majeure étant supportée au minimum quatre ans, jusqu'à la sortie de deux majeures suivantes. Drupal 10 est sorti le 15 décembre 2022, Drupal 11 en août 2024, Drupal 12 arrive en décembre 2026. La conséquence pratique est simple : sur un site Drupal, une montée de version majeure n'est plus un événement exceptionnel de refonte, c'est une ligne récurrente du budget de maintenance, à prévoir tous les deux à quatre ans.

La bonne nouvelle, c'est que depuis Drupal 9 ces montées de version sont incomparablement moins lourdes que le saut Drupal 7 vers Drupal 8. Le travail consiste à supprimer les appels au code déprécié, à mettre à jour les modules contribués, et à vérifier les modules sur mesure. Des outils comme Upgrade Status et Rector automatisent une part significative de la détection. La mauvaise nouvelle, c'est que ce travail doit être fait, et qu'il est cumulatif : un site qui saute une majeure paiera deux fois la facture à la suivante.

Si votre site Drupal a été livré par une agence avec laquelle vous n'êtes plus en relation, c'est précisément le moment de reprendre la main, avant l'échéance et pas après. Nous avons documenté ce cas de figure sur notre page consacrée à la maintenance Drupal, qui explique comment nous reprenons un site dont nous n'avons pas écrit la première ligne.

PHP 8.2 meurt le 31 décembre 2026 : la contrainte qui commande toutes les autres

PHP 8.2 atteint sa fin de vie le 31 décembre 2026 et ne recevra plus aucun correctif de sécurité après cette date. Les branches encore suivies à ce moment-là seront PHP 8.3, en sécurité seule jusqu'au 31 décembre 2027, PHP 8.4, en sécurité jusqu'au 31 décembre 2028, et PHP 8.5, sortie le 20 novembre 2025 et suivie jusqu'au 31 décembre 2029. Tout ce qui précède PHP 8.2 est déjà hors support.

Si vous ne retenez qu'une échéance de cet article, retenez celle-ci. PHP est la couche sur laquelle reposent Joomla, Drupal, WordPress et PrestaShop. Une version de PHP sans correctif de sécurité, c'est une faille potentielle sous l'ensemble de votre site, quel que soit le soin apporté au CMS au-dessus. Et contrairement à une vulnérabilité dans un composant d'agenda obscur, une vulnérabilité dans l'interpréteur PHP concerne des millions de serveurs, ce qui garantit qu'elle sera exploitée massivement et automatiquement dans les heures qui suivent sa publication.

Choisir la bonne cible, pas la plus haute

La tentation, quand on décide enfin de monter, est de viser la dernière version disponible. C'est rarement le meilleur calcul. PHP 8.5 est la plus récente, mais c'est aussi celle dont l'écosystème d'extensions est le moins mûr, et il n'est pas rare qu'une bibliothèque tierce mette plusieurs mois à s'y adapter. PHP 8.4, dont le support de sécurité court jusqu'au 31 décembre 2028, offre aujourd'hui le meilleur compromis entre durée de couverture et compatibilité réelle des extensions.

C'est d'ailleurs la version que le projet Joomla recommande officiellement pour Joomla 6, et elle satisfait très largement les prérequis de Drupal 11 et 12 comme de WordPress. Viser PHP 8.4 en 2026 vous donne deux ans de tranquillité et vous évite d'être le terrain d'essai de vos propres extensions.

Une montée de PHP ne se fait jamais en production

Le protocole qui fonctionne tient en cinq étapes, et il n'a rien d'exotique : une sauvegarde complète et restaurée au moins une fois pour prouver qu'elle fonctionne, un clone du site sur un environnement de préproduction identique, la bascule de PHP sur ce clone, une analyse de compatibilité du code puis une recette fonctionnelle page par page sur les parcours critiques, et enfin la bascule en production sur un créneau où quelqu'un est disponible pour revenir en arrière.

La dernière étape est celle que l'on saute le plus souvent, et c'est celle qui coûte le plus cher quand on l'a sautée. Une bascule de PHP le vendredi à dix-huit heures est une décision que l'on regrette le samedi matin. Sur ce point, notre retour d'expérience de dépannage de site internet est sans ambiguïté : une part importante des interventions d'urgence que nous traitons sont des changements d'environnement réalisés sans préproduction ni fenêtre de retour arrière.

WordPress : pas de fin de support, mais un plancher qui remonte

WordPress ne publie pas de calendrier de fin de vie par version majeure comparable à celui de Joomla ou de Drupal, et c'est ce qui rend son cas trompeur. WordPress 6.9, sorti le 2 décembre 2025, accepte encore PHP 7.2.24 au minimum. WordPress 7.0 relève ce plancher à PHP 7.4, et les sites restés sur PHP 7.2 ou 7.3 ne recevront pas cette mise à jour : ils resteront sur la branche 6.9.

Le risque WordPress n'est donc pas celui d'une date couperet, mais celui d'un décrochage silencieux. Un site dont l'hébergement est resté sur une vieille version de PHP cesse simplement d'être proposé à la mise à jour, et son administrateur peut très longtemps croire que tout va bien parce qu'aucun message d'alerte ne s'affiche. Pendant ce temps, l'écart entre la version installée et la version courante se creuse, et les extensions publient des mises à jour qui ne sont plus compatibles avec le socle.

Le minimum recommandé pour WordPress en 2026 est PHP 8.3, et PHP 8.4 ou 8.5 pour les performances. Là encore, la question à poser à votre hébergeur n'est pas « mon site fonctionne-t-il », mais « sur quelle version de PHP tourne-t-il, et jusqu'à quand cette version est-elle corrigée ». La réponse tient en une ligne et détermine votre exposition pour les deux ans qui viennent.

Le vrai sujet WordPress reste ailleurs : dans le volume d'extensions installées. Un site vitrine qui embarque trente extensions accumule trente calendriers de maintenance indépendants, trente éditeurs susceptibles d'abandonner leur produit, et trente surfaces d'attaque. La réduction de ce nombre est souvent l'action la plus rentable d'un plan de maintenance, bien avant la montée de version elle-même.

Depuis le 11 septembre 2026, le Cyber Resilience Act accélère le rythme des correctifs

Les obligations de signalement du règlement européen Cyber Resilience Act sont entrées en application le 11 septembre 2026, et l'ensemble du texte deviendra pleinement applicable le 11 décembre 2027. Les fabricants de produits comportant des éléments numériques doivent désormais signaler à l'ENISA et à leur CSIRT national toute vulnérabilité activement exploitée, avec une alerte précoce sous 24 heures et une notification détaillée sous 72 heures.

Précisons tout de suite ce que cela ne veut pas dire, parce que le sujet circule beaucoup et souvent mal. Une PME qui exploite un site vitrine n'est pas un « fabricant de produit comportant des éléments numériques » au sens du règlement, et ce texte ne lui impose pas directement de déclaration. Ce ne sont pas vos obligations qui changent : c'est le comportement de vos fournisseurs.

Les éditeurs de CMS, les éditeurs d'extensions commerciales et les hébergeurs entrent, eux, dans le champ du règlement. La conséquence concrète pour votre site est double. D'une part, le rythme de publication des correctifs va s'accélérer et devenir plus visible, parce qu'un éditeur qui signale une vulnérabilité exploitée sous 24 heures ne peut plus la corriger discrètement dans une version mineure trois mois plus tard. D'autre part, la fenêtre entre la publication d'un correctif et l'exploitation massive de la faille va se réduire, puisque la publication elle-même devient un signal public.

Traduit en termes de maintenance, cela signifie qu'un rythme de mise à jour trimestriel, encore acceptable il y a cinq ans, ne l'est plus. La surveillance doit être continue et l'application des correctifs de sécurité doit se compter en jours, pas en trimestres. C'est exactement ce qui distingue un contrat de maintenance web d'une intervention ponctuelle : non pas la compétence mobilisée, mais la fréquence à laquelle quelqu'un regarde.

Monter de version ou refondre : comment trancher sans se tromper

La montée de version se justifie quand le site répond encore au besoin métier et que sa structure éditoriale est saine. La refonte se justifie quand le besoin a changé, quand l'ergonomie ou l'accessibilité ne sont plus au niveau, ou quand le coût de remise à niveau technique dépasse la moitié du coût d'un site neuf. Entre les deux, le critère décisif n'est pas technique mais fonctionnel : le site fait-il encore ce que vous attendez de lui.

Le réflexe le plus coûteux consiste à transformer une contrainte de calendrier en projet de refonte. Une fin de support crée une urgence technique de quelques semaines. Une refonte est un projet de plusieurs mois qui mobilise vos équipes métier, votre direction de la communication et souvent votre direction générale. Lancer la seconde parce que la première arrive revient à répondre à une échéance de trois mois par un chantier de six, et à passer l'intervalle hors support.

La séquence saine est l'inverse. On sécurise d'abord le socle, en montant PHP puis le CMS, ce qui remet le site dans une zone couverte. On dispose alors du temps nécessaire pour instruire sérieusement la question de la refonte, avec un cahier des charges plutôt qu'avec un pistolet sur la tempe. Et si la refonte est effectivement décidée, elle part d'un site à jour, ce qui simplifie considérablement la reprise du contenu.

Les cinq questions qui suffisent à décider

Première question : votre site atteint-il ses objectifs de trafic et de contacts entrants. Si oui, la structure fonctionne et mérite d'être conservée. Deuxième question : la charte graphique et l'ergonomie tiennent-elles encore la comparaison avec vos concurrents directs. Troisième question : combien de développements spécifiques le site embarque-t-il, et sont-ils documentés. Quatrième question : le site est-il conforme aux exigences d'accessibilité qui s'appliquent à votre organisation. Cinquième question : votre équipe sait-elle administrer le site sans appeler un prestataire pour chaque modification.

Trois réponses positives sur cinq orientent vers la montée de version. Trois réponses négatives orientent vers la refonte. Et dans tous les cas, ces questions se traitent bien mieux dans un audit formalisé, avec des mesures, que dans une conversation de couloir. C'est l'objet de notre démarche d'amélioration continue : mesurer avant d'arbitrer, puis avancer par incréments budgétés plutôt que par grands sauts.

Ce que coûte une montée de version majeure en France en 2026

Sur le marché français en 2026, le taux journalier d'une agence web se situe entre 600 et 1 200 euros hors taxes selon la séniorité des profils mobilisés, contre 450 à 650 euros hors taxes pour un développeur freelance confirmé. Une migration Joomla d'ancienne génération démarre autour de 490 euros hors taxes chez les prestataires français, et une montée de version majeure de Drupal représente couramment 10 à 30 pour cent du coût initial du site.

Ces chiffres sont des ordres de grandeur de marché, relevés publiquement, et ils appellent trois commentaires. Le premier, c'est que l'écart entre 490 euros et 30 pour cent du coût d'un site ne traduit pas une incohérence du marché, mais deux réalités différentes. Un site vitrine de quinze pages avec un template standard et cinq extensions courantes se monte effectivement en une à deux journées. Un site institutionnel avec un intranet, des connecteurs métier et quatre modules sur mesure relève d'un tout autre exercice.

Le deuxième commentaire porte sur la structure du devis. Un chiffrage sérieux distingue toujours quatre lignes : l'inventaire et l'analyse de compatibilité, la mise en place de la préproduction, la montée de version proprement dite, et la recette. Si l'on vous présente un prix global sans ce découpage, vous ne pouvez ni comparer les offres, ni comprendre ce qui dérapera si quelque chose dérape. Les développements spécifiques, en particulier, doivent faire l'objet d'une ligne séparée, parce que ce sont eux qui portent l'essentiel de l'incertitude.

Le troisième commentaire est le plus important pour une direction financière. Le coût d'une montée de version planifiée et celui de la même opération menée dans l'urgence après un incident n'ont rien à voir. La première se négocie, s'étale, se programme sur un creux d'activité. La seconde se paie en heures d'urgence, avec en prime le nettoyage d'une compromission, la restauration d'une sauvegarde, et parfois la notification à la CNIL si des données personnelles ont été touchées. Reporter une montée de version ne supprime pas la dépense : cela la déplace vers le scénario le plus cher.

Un dernier repère pour situer l'enjeu : sur le marché français, une refonte de site de taille intermédiaire, pilotage, design, développement et recette compris, se situe entre 30 000 et 80 000 euros hors taxes pour une durée de deux à six mois. Comparé à cela, une montée de version qui prolonge la vie utile d'un site de deux à quatre ans est rarement l'arbitrage le moins rentable.

Le plan des douze prochaines semaines

Un plan réaliste tient en quatre étapes, réparties sur douze semaines : relever l'état exact de l'existant en semaine 1, obtenir les devis et arbitrer en semaines 2 à 4, exécuter la montée de version sur préproduction en semaines 5 à 10, basculer en production et surveiller en semaines 11 et 12. Ce rythme place la bascule avant les échéances de décembre 2026, avec une marge utile.

La première semaine ne coûte rien et conditionne tout le reste. Il s'agit de produire une fiche d'identité du site, en une page, qui répond à six questions : quel CMS et quelle version exacte, quelle version de PHP, quelle version de base de données, combien d'extensions et lesquelles, quels développements spécifiques et par qui, et où sont les sauvegardes. Dans la plupart des organisations que nous accompagnons, cette fiche n'existe pas, et c'est son absence qui rend impossible toute évaluation sérieuse.

La deuxième étape consiste à faire chiffrer sur cette base, en demandant explicitement le découpage en quatre lignes évoqué plus haut. Un prestataire qui refuse de détailler son chiffrage sur une opération aussi normée est un signal. Profitez de cette phase pour poser la question du cycle suivant : que se passe-t-il en 2028, quand Joomla 6 arrivera en fin de support correctif et que Drupal 13 pointera. Un prestataire qui n'a pas de réponse à cette question vous vendra le même chantier en urgence dans deux ans.

La troisième étape est technique et doit se dérouler hors production, sans exception. La quatrième, souvent négligée, consiste à surveiller activement les deux semaines qui suivent la bascule : les journaux d'erreurs du serveur, les temps de réponse, les positions sur vos requêtes principales, et les formulaires, qui sont le point de défaillance le plus fréquent et le moins visible après une montée de version. Un formulaire de contact cassé ne déclenche aucune alerte : il produit simplement un silence que l'on interprète, à tort, comme un creux commercial.

Enfin, si vous gérez plusieurs sites, ne traitez pas ces douze semaines site par site. Le recensement se fait une fois pour l'ensemble du parc, les versions cibles se décident une fois, et les montées de version s'enchaînent en commençant par le site le moins critique, qui sert de répétition générale. C'est toute la logique de l'infogérance de parc digital : mutualiser l'analyse, industrialiser l'exécution, et ne payer qu'une fois l'apprentissage.

Questions fréquentes

Mon site va-t-il cesser de fonctionner à la date de fin de support ?

Non. Un site en fin de support continue de fonctionner normalement, parfois pendant des années. Ce qui s'arrête, c'est la publication de correctifs pour votre version. Le site devient progressivement vulnérable aux failles découvertes après cette date, et ces failles sont publiées dans des bases de données consultables par tous, avec la liste précise des versions affectées. Le risque n'est pas la panne : c'est la compromission.

Combien de temps faut-il prévoir pour une montée de version ?

Comptez huit à douze semaines entre la décision et la bascule pour un site vitrine standard, dont une grande partie en attente de devis, de validation interne et de disponibilité des équipes. Le travail technique lui-même représente souvent quelques jours seulement. C'est pourquoi une échéance à décembre 2026 se traite en septembre, et non en novembre : ce n'est pas le chantier qui est long, c'est le processus de décision qui l'entoure.

Puis-je rester sur Joomla 5 après octobre 2026 ?

Oui, et de façon raisonnablement sûre jusqu'au 12 octobre 2027, puisque Joomla 5 continue de recevoir les correctifs de sécurité pendant cette année de sécurité seule. En revanche, aucun bug fonctionnel ne sera plus corrigé sur cette branche à partir du 13 octobre 2026, et votre hébergement devra de toute façon passer à PHP 8.3 au minimum pour envisager Joomla 6 ensuite. Utilisez cette année comme un délai de préparation, pas comme un sursis passif.

Comment savoir sur quelle version de PHP tourne mon site ?

Dans Joomla, ouvrez Système puis Informations système ; dans Drupal, Rapports puis Rapport d'état ; dans WordPress, Outils puis Santé du site puis Informations. Votre panneau d'hébergement affiche également cette information et permet généralement de changer de version. Si vous y lisez PHP 8.2 ou une version antérieure, vous avez une action à programmer avant le 31 décembre 2026.

Faut-il changer d'hébergeur si le mien ne propose pas PHP 8.3 ?

Commencez par le lui demander explicitement, en écrivant, et en demandant une date. Beaucoup d'hébergeurs proposent des versions récentes de PHP sans les activer par défaut, et l'activation ne prend que quelques minutes. Si la réponse est qu'aucune version supérieure à PHP 8.2 n'est prévue, la question est tranchée : un hébergeur qui ne suit pas le calendrier de PHP ne suivra pas davantage celui des correctifs de sécurité, et le changement devient la seule option raisonnable.

Faire le point avant les échéances de décembre

Les dates sont connues, publiques, et elles ne bougeront pas. Le 13 octobre 2026 pour Joomla 5, le 9 décembre 2026 pour Drupal 10, le 31 décembre 2026 pour PHP 8.2. Ce qui varie d'une organisation à l'autre, ce n'est pas l'échéance : c'est le moment où quelqu'un décide de la regarder en face.

Si vous ne savez pas aujourd'hui sur quelle version de PHP tourne votre site, combien d'extensions il embarque et quand sa dernière sauvegarde a été restaurée avec succès, la première action n'est pas de demander un devis de migration : c'est de faire établir cet état des lieux. Nous réalisons ce diagnostic dans le cadre de nos audits de site web, et il débouche sur un plan chiffré et daté, que vous restez libre de faire exécuter par qui vous voulez.

Pulsar Agency accompagne depuis 2005 des PME et des grands comptes sur la maintenance, l'infogérance et la TMA de leurs sites existants, en Île-de-France et dans les Hauts-de-France. Si les échéances de cet article concernent votre site, parlons de votre contrat de maintenance avant décembre plutôt qu'après.