Introduction
Fin 2025, PHP 8.1 est officiellement sorti du support de sécurité. Aucun communiqué de presse, aucune bannière rouge sur les tableaux de bord, aucun mail d'alerte. La date est passée, et une bonne partie des sites français concernés continue de tourner exactement comme la veille. C'est bien là le problème.
Le sujet est inconfortable pour une raison simple : il mélange deux terrains sur lesquels un dirigeant se sent rarement légitime. La technique pure d'un côté, la question d'argent de l'autre. Résultat, beaucoup préfèrent ne pas ouvrir le dossier. On repousse. On se dit que le prestataire aurait prévenu s'il y avait urgence.
Cet article propose de faire l'inverse. À la fin de la lecture, vous saurez diagnostiquer la version de PHP qui sert réellement vos pages en trois minutes, évaluer votre exposition sans céder à la panique, et surtout déterminer qui doit sortir le chéquier selon ce que dit, ou ne dit pas, votre contrat.
Le parti pris est assumé : ce n'est pas un problème technique. C'est un problème de contrat mal rédigé.
Ce que « fin de support » veut dire concrètement
Première confusion à lever, et elle est fréquente : il existe deux dates de fin, pas une.
Le support actif s'arrête d'abord. À partir de ce moment, les développeurs de PHP ne corrigent plus les bugs fonctionnels de la version. Un comportement bizarre restera bizarre. Puis vient, un ou deux ans plus tard, la fin du support de sécurité. Là, plus aucun correctif de faille n'est publié. Jamais. C'est cette seconde date qui compte vraiment, et c'est celle que PHP 8.1 a franchie en décembre 2025.
Le calendrier officiel, pour situer :
- PHP 8.1 : sortie en novembre 2021, fin du support de sécurité en décembre 2025
- PHP 8.2 : fin du support de sécurité fin 2026
- PHP 8.3 : fin du support de sécurité fin 2027
- PHP 8.4 : fin du support de sécurité fin 2028
- PHP 8.5 : la plus récente, horizon 2029
Autrement dit, si votre site tourne aujourd'hui en 8.2, vous avez un peu de temps. Mais pas tant que ça.
Ce qui ne se passe pas le jour J
Rien. Absolument rien. Le site ne s'éteint pas. Les pages continuent de s'afficher, les formulaires d'envoyer, les commandes de tomber. Aucune notification n'apparaît dans le back-office, aucun mail de l'hébergeur, aucun bandeau d'avertissement.
Et c'est précisément ce silence qui rend le sujet dangereux. Une panne, ça se voit. Une obsolescence, non.
Ce qui se passe vraiment
Les failles découvertes après la date de fin de support restent ouvertes. Indéfiniment. Et comme elles sont publiées, documentées, indexées dans les bases publiques de vulnérabilités, elles deviennent accessibles à quiconque sait lire.
Le scénario type n'a rien de spectaculaire : un robot balaie des milliers de sites, identifie ceux qui répondent avec une empreinte de version vulnérable, et tente l'exploitation en série. Personne ne vous vise. Vous êtes juste dans la liste.
La nuance des backports, qui mérite qu'on s'y arrête
Il existe une exception, et elle est mal connue. Certaines distributions Linux (Debian, Red Hat Enterprise Linux) et certains panneaux d'hébergement maintiennent leurs propres paquets PHP. Ils rétroportent les correctifs de sécurité critiques sur des versions officiellement mortes, parfois pendant des années.
Donc oui, un PHP 8.1 packagé par Debian peut continuer à recevoir des correctifs après décembre 2025. Comment le vérifier ? En demandant à votre hébergeur, tout simplement, quelle est la politique de maintenance de la version installée sur votre serveur. La question tient en une ligne.
Mais attention à ne pas transformer cette nuance en excuse. Un backport couvre les failles critiques du cœur de PHP, pas l'écosystème autour. Vos extensions, vos bibliothèques, vos passerelles de paiement, elles, vont progressivement cesser de supporter la 8.1. Le backport vous donne du répit, il ne vous dispense de rien.
Diagnostiquer sa version de PHP en trois minutes, sans compétence technique
Bonne nouvelle : vous n'avez besoin de personne pour cette étape. Quatre méthodes, de la plus rapide à la plus fiable.
Méthode 1 : l'en-tête HTTP
Trente secondes, depuis n'importe quel navigateur. Ouvrez votre site, appuyez sur F12 pour afficher les outils de développement, allez dans l'onglet Réseau, rechargez la page, cliquez sur la première ligne de la liste. Cherchez un en-tête nommé X-Powered-By. S'il est présent, il affiche quelque chose du genre « PHP/8.1.27 ».
Limite importante : beaucoup d'hébergeurs masquent volontairement cet en-tête, justement pour ne pas afficher leur version aux robots. Une absence de réponse n'est donc pas une bonne nouvelle. C'est simplement une absence d'information.
Méthode 2 : le tableau de bord du CMS
Plus fiable, et accessible à tous. Selon votre outil :
- WordPress : Outils → Santé du site → Informations → Serveur. La version y est affichée en clair, avec parfois une alerte si elle est obsolète.
- PrestaShop : Paramètres avancés → Informations. Tout est regroupé sur une seule page.
- Drupal : Rapports → Rapport d'état. Drupal est d'ailleurs l'un des rares CMS à signaler franchement une version en fin de vie.
- Joomla : Système → Informations système.
- Shopify : question sans objet. La plateforme est en SaaS, l'infrastructure ne vous appartient pas, et c'est précisément l'un de ses arguments commerciaux.
Méthode 3 : le panneau d'hébergement
C'est la source la plus proche de la vérité, puisque c'est là que la version se configure.
- cPanel : rubrique « Sélecteur de version PHP » ou « MultiPHP Manager »
- Plesk : Sites web et domaines → Paramètres PHP
- o2switch : cPanel intégré, même chemin
- OVH : espace client → Hébergements → onglet Multisite ou FTP-SSH selon l'offre
- Hostinger : hPanel → Avancé → Configuration PHP
- Infomaniak : Manager → Hébergement → Sites → Configuration avancée
Un piège fréquent ici, et il coûte cher : le multi-domaine. Chaque domaine, chaque sous-domaine, parfois chaque dossier peut tourner sur une version différente. Votre site principal est en 8.3, très bien. Mais le vieux blog sur blog.votresite.fr, oublié depuis trois ans, tourne peut-être encore en 7.4. Et il partage le même serveur.
Méthode 4 : les outils externes
Scanners en ligne, extensions de navigateur comme Wappalyzer, ou une simple requête en ligne de commande pour ceux que ça amuse. C'est rapide, c'est visuel, et c'est régulièrement faux.
Pourquoi ? Parce que ces outils travaillent par empreinte. Ils déduisent la version à partir d'indices indirects, et ils lisent mal les versions mineures. Un outil qui vous annonce « PHP 8 » sans plus de précision ne vous apprend rien d'exploitable : entre 8.0 et 8.4, il y a quatre ans d'écart et deux versions déjà mortes.
Le piège majeur, celui qui trompe même les techniciens
PHP-CLI n'est pas PHP-FPM.
Un serveur peut parfaitement afficher « PHP 8.3 » quand on l'interroge en ligne de commande, et servir vos pages web en 8.1. Ce sont deux binaires distincts, deux configurations distinctes. On a vu des prestataires de bonne foi affirmer que tout était à jour, sur la base d'un simple php -v en SSH. Ils n'avaient regardé que la moitié du serveur.
La seule vérification qui fasse foi consiste à déposer un fichier phpinfo temporaire à la racine du site, l'ouvrir dans un navigateur, lire la version en haut de page, puis le supprimer immédiatement.
Ce dernier point n'est pas une précaution de forme. Un fichier phpinfo laissé en ligne expose la totalité de la configuration serveur : chemins absolus, modules chargés, variables d'environnement, parfois des identifiants. C'est un cadeau pour un attaquant. Le nombre de sites qui traînent un info.php oublié à leur racine depuis une intervention de 2019 est franchement déprimant.
Évaluer votre exposition réelle : toutes les versions obsolètes ne se valent pas
Découvrir qu'on tourne en 8.1 ne signifie pas qu'il faut appeler un développeur ce soir. Encore faut-il mesurer ce qu'on risque vraiment.
Quatre facteurs suffisent à se faire une idée juste.
La nature du site. Un site vitrine ne joue pas dans la même catégorie qu'une boutique en ligne, qui elle-même ne joue pas dans la même catégorie qu'un applicatif métier avec comptes utilisateurs.
Le volume de données personnelles traitées. Zéro donnée, zéro enjeu réglementaire. Une base de deux mille clients avec adresses et historiques de commande, c'est un tout autre dossier.
La surface exposée. Combien de portes d'entrée ? Formulaires, espace client, tunnel de paiement, upload de fichiers, API ouverte. Chaque porte est un point d'entrée potentiel.
La présence d'un pare-feu applicatif en amont. Un WAF, qu'il vienne de l'hébergeur ou d'un service type Cloudflare, filtre une bonne partie des tentatives automatisées. Ce n'est pas une armure, mais ça change le calcul du risque.
Le site vitrine de dix pages
Pas de formulaire, pas de base clients, pas de paiement. Le risque est faible et l'urgence relative. On peut planifier tranquillement.
Attention toutefois à ne pas conclure qu'il n'y a rien à faire. Un site compromis, même vitrine, peut se retrouver blacklisté par Google, servir de relais à des campagnes de spam, ou héberger à votre insu des pages de contrefaçon qui plomberont durablement votre référencement. La réparation coûte alors bien plus que la migration.
Le e-commerce avec base clients
Ici, le curseur change de côté. Risque élevé, et surtout dimension réglementaire.
Le RGPD impose des « mesures techniques et organisationnelles appropriées » pour protéger les données. Faire tourner une version de PHP sans support de sécurité pendant des mois, en connaissance de cause, devient un argument opposable en cas de fuite. Ce n'est plus seulement une question de sécurité informatique, c'est une question de responsabilité.
Le vrai vecteur : les extensions et les thèmes
Point souvent mal compris, et qui mérite d'être dit clairement : dans l'immense majorité des piratages de sites, ce n'est pas PHP lui-même qui est exploité.
Ce sont les composants tiers. Un plugin de formulaire abandonné par son auteur. Un thème acheté sur une marketplace et jamais mis à jour. Une extension de galerie photo installée en 2020 pour une opération ponctuelle, et restée là.
Or ces composants restent bloqués sur les vieilles versions de PHP précisément parce que le site ne migre pas. Le cercle est vicieux : on ne met pas à jour PHP parce que les extensions ne suivraient pas, et les extensions ne sont plus maintenues parce que leurs auteurs ont abandonné le support des vieilles versions.
Le coût invisible
C'est celui que personne ne chiffre, et pourtant il tombe toujours.
Progressivement, les nouvelles versions de plugins refusent de s'installer. Votre passerelle de paiement annonce qu'elle abandonne le support de PHP 8.1 au prochain trimestre. Une API tierce que vous consommez change son SDK, et le nouveau SDK exige 8.2 minimum.
Chacun de ces événements pris isolément est un détail. Mis bout à bout sur dix-huit mois, ils transforment une migration simple en refonte partielle. Le site n'a pas cassé, il s'est juste retrouvé enfermé.
Ce que coûte réellement une migration PHP
Question légitime, réponse honnête : ça dépend, et l'écart entre les scénarios est considérable.
Les trois scénarios de coût
La bascule sèche. Site standard, extensions à jour, aucun développement spécifique. Concrètement : on coche une case dans le panneau d'hébergement, on parcourt le site, on teste les formulaires et le tunnel de commande, on vérifie les logs pendant quelques jours. Compter quelques heures. C'est le scénario le plus fréquent sur les sites bien entretenus, et il représente probablement la majorité des cas.
La migration avec ajustements. Il existe du code sur mesure, des fonctions dépréciées à remplacer, des comportements qui ont changé entre versions. PHP 8 a durci le typage, modifié la gestion de certaines erreurs, retiré des fonctions historiques. Rien d'insurmontable, mais il faut ouvrir le code, corriger, tester, redéployer. On passe de quelques heures à quelques jours.
La refonte partielle imposée. Le scénario qu'on redoute. Le thème n'est plus maintenu par son auteur. Une extension propriétaire, achetée à un éditeur qui a fermé, refuse de fonctionner. Un développement spécifique livré sans documentation par un prestataire injoignable. Là, on ne migre plus, on reconstruit.
Ce qui fait exploser la facture
Toujours les mêmes quatre coupables, et ils sont remarquablement constants d'un dossier à l'autre.
Le code sur mesure non documenté et non versionné. Personne ne sait pourquoi cette fonction existe, ce qu'elle fait exactement, ni ce qui casse si on la touche. Chaque modification devient une exploration.
L'absence d'environnement de préproduction. Impossible de tester sans risquer la production. On travaille donc de nuit, en priant, avec un plan de retour arrière approximatif. Le stress ajoute des heures, et les heures ajoutent des euros.
Les extensions modifiées à la main ou nulled. Une extension premium piratée, ou une extension légitime dont on a bricolé le code directement au lieu de passer par les mécanismes prévus. Toute mise à jour écrase les modifications, donc on ne met plus à jour, donc on accumule la dette.
Les dépendances abandonnées. Une bibliothèque dont le dépôt affiche « dernier commit il y a quatre ans ». Il faudra la remplacer, et le remplacement ne fera jamais exactement la même chose.
Les ordres de grandeur
Donner des fourchettes est toujours délicat, mais voici des repères raisonnables sur le marché français.
- Site vitrine standard, CMS à jour : de quelques centaines d'euros pour la bascule et les vérifications
- Boutique en ligne sans développement spécifique : entre mille et trois mille euros, tests du tunnel de commande inclus
- Site avec développements sur mesure : impossible à chiffrer sans audit préalable, l'écart pouvant aller de un à dix
Retenez surtout ceci : la variable dominante n'est pas la taille du site. Un site de trois cents pages parfaitement standard migre plus vite qu'un site de huit pages bourré de code artisanal. C'est l'état du code qui décide, pas le volume.
Conséquence directe, et c'est un bon test de sérieux : un devis crédible commence toujours par un audit de compatibilité, facturé séparément et pour un montant modeste. Ce n'est pas une manœuvre commerciale, c'est la seule façon de savoir dans quel scénario on se trouve.
Un prestataire qui annonce un prix ferme sans avoir regardé le code fait l'une de deux choses. Soit il gonfle largement pour se couvrir, et vous payez trop. Soit il sous-estime, et il reviendra en cours de route avec un avenant. Dans les deux cas, méfiance.
Qui paie ? La vraie question, et sa vraie réponse
On arrive au cœur du sujet. Et la réponse ne se trouve ni dans la technique, ni dans le bon sens, ni dans la qualité de la relation avec votre prestataire.
Elle se trouve dans votre contrat.
Le point de départ : lire son contrat, pas son ressenti
Beaucoup de dirigeants abordent cette conversation avec une conviction : « je paie une maintenance mensuelle, donc c'est inclus ». C'est parfois vrai. C'est souvent faux. Et le ressenti ne pèse rien face à une clause.
Quatre régimes contractuels existent, avec des conséquences très différentes.
Le contrat de création seule, livré et soldé. Le prestataire a construit le site, l'a livré, vous l'avez recetté et payé. La relation contractuelle est éteinte. Une migration PHP est une prestation nouvelle, elle se commande et elle se paie. Aucune ambiguïté, aucun recours. C'est frustrant, mais c'est net.
Le contrat de maintenance corrective. C'est ici que se joue la nuance décisive, et elle échappe à presque tout le monde. La maintenance corrective couvre la correction de ce qui casse. Elle ne couvre pas l'évolution de ce qui vieillit.
Or une version de PHP en fin de support ne casse rien. Le site fonctionne. Il est simplement exposé. Donc, sauf mention explicite de la sécurité ou de l'obsolescence dans le périmètre, la migration PHP tombe le plus souvent en dehors du forfait. C'est la lecture la plus courante, et elle est difficilement contestable sur le texte.
Le contrat de maintenance évolutive ou TMA. Là, on change de logique. La tierce maintenance applicative inclut généralement le maintien du socle technique, à condition que le périmètre le mentionne. Cherchez les termes « maintien en condition opérationnelle », « socle technique », « environnement d'exécution ». S'ils sont présents, la migration entre normalement dans le forfait.
Le contrat d'infogérance ou d'hébergement managé. Le cas le plus piégeux, parce qu'il crée une frontière que personne ne pense à tracer à la signature. En infogérance, la version de PHP installée sur le serveur relève du prestataire : c'est son infrastructure, il la maintient. Mais la compatibilité de votre application avec cette version reste à votre charge.
Traduction concrète : l'hébergeur bascule le serveur en 8.3 comme il en a le droit, votre boutique tombe en panne parce qu'une extension ne suit pas, et il vous répond, sans mauvaise foi, que ce n'est pas son périmètre. Techniquement, il a raison. C'est la frontière classique du litige, et elle produit des conversations très tendues.
Les formulations à chercher dans votre contrat
Prenez dix minutes, ouvrez le PDF, utilisez la recherche. Quatre expressions méritent votre attention.
« Maintien en condition opérationnelle » : formule large, plutôt favorable au client. Elle englobe généralement le socle technique, donc la version de PHP.
« Mise à jour de sécurité » : ambigu. Le prestataire soutiendra qu'il s'agit des mises à jour du CMS et des extensions, pas du moteur PHP. Vous soutiendrez l'inverse. Sans précision, la discussion s'enlise.
« Évolution technologique » : presque toujours utilisé pour exclure. « Les évolutions technologiques font l'objet d'un devis séparé. » Si cette phrase figure dans votre contrat, la messe est dite.
« Obsolescence » : rare, et c'est dommage. Quand le terme est présent et assorti d'un engagement de délai, tout devient limpide.
Et si le contrat ne dit rien ?
Cas très fréquent, notamment sur les prestations signées avant 2020. Le contrat est muet. À qui profite le silence ?
Le droit français apporte ici un élément que beaucoup de clients ignorent : le prestataire professionnel est tenu d'une obligation de conseil envers un client non-sachant. Cette obligation ne se limite pas à répondre aux questions posées. Elle impose d'alerter spontanément sur les risques connus du métier.
La date de fin de support de PHP 8.1 était publique depuis 2021. Elle figure sur le site officiel de PHP, elle est reprise dans toute la presse spécialisée, elle fait partie du bagage de base de n'importe quel professionnel du web. Un prestataire qui maintient un site ne peut pas sérieusement plaider l'ignorance.
Alors la question devient : ce prestataire savait, il n'a rien dit pendant quatre ans, et il vous facture aujourd'hui l'urgence qu'il a lui-même laissé venir ?
Cette question, posée calmement et par écrit, change souvent le ton d'une négociation. Elle ne garantit pas la gratuité. Elle rééquilibre la discussion.
La zone grise la plus fréquente
Voici le scénario qui revient le plus souvent, et qui n'a pas de réponse tranchée.
Le prestataire a développé, il y a trois ans, un module sur mesure. Une connexion à votre logiciel de gestion, un configurateur de produit, un système de réservation. Ce module est incompatible avec les versions récentes de PHP. Sa mise en conformité relève-t-elle de la garantie ou d'une prestation nouvelle ?
L'argument du prestataire : le module a été livré conforme et fonctionnel, dans l'environnement technique de l'époque. Il a été recetté et accepté. Une adaptation à un nouvel environnement, trois ans plus tard, est un travail supplémentaire. Il se facture.
L'argument du client : un professionnel qui développe du code sur mesure engage sa compétence. Écrire en 2022 du code qui utilise des fonctions déjà signalées comme dépréciées, c'est livrer un objet à durée de vie artificiellement raccourcie. Le défaut est à l'origine, pas dans l'environnement.
Ce que dit la pratique : la solution se trouve presque toujours à mi-chemin. Le prestataire prend à sa charge les corrections liées à des pratiques qui étaient déjà déconseillées au moment du développement, le client finance les adaptations liées aux évolutions réellement postérieures. Ce n'est écrit nulle part, mais c'est l'arbitrage qui permet aux deux parties de continuer à travailler ensemble.
Et soyons honnêtes : le partage se négocie surtout en fonction de la valeur de la relation commerciale. Un prestataire qui facture cent mille euros par an à un client ne va pas se battre pour deux jours de développement.
Le cas de l'hébergeur qui force la bascule
Dernier scénario, et le plus révélateur.
L'hébergeur annonce, avec un préavis de deux ou trois mois, qu'il retire PHP 8.1 de son parc. À la date annoncée, il bascule. Le site casse. Qui répare ?
La réaction spontanée est de crier au coup de force. Mais regardons les faits. Un préavis a été envoyé. Une date a été fixée. Une alternative a été proposée. Tout était connu, à l'avance, par écrit.
Ce scénario en apparence subi est en réalité le plus prévisible de tous. Et donc le moins excusable pour un prestataire dont le métier est justement de surveiller ces annonces. Si personne n'a rien vu venir alors qu'un mail annonçait la date trois mois plus tôt, ce n'est pas un accident technique. C'est un défaut de suivi.
Petit conseil pratique au passage : vérifiez à quelle adresse mail l'hébergeur envoie ses communications techniques. Dans un nombre gênant de cas, c'est une adresse créée par l'ancien prestataire, que plus personne ne relève depuis des années.
Comment aborder la conversation avec votre prestataire
Pas besoin de monter au créneau. Quatre questions suffisent, posées par écrit.
Pourquoi l'écrit ? Pour deux raisons. D'abord parce qu'une réponse écrite engage, alors qu'un « t'inquiète, c'est bon » au téléphone n'engage rien. Ensuite parce que si la relation se dégrade plus tard, vous disposerez d'une trace de ce qui vous a été affirmé, et à quelle date.
Les quatre questions :
- Quelle version de PHP sert actuellement mes pages, en production ? Notez la formulation. Pas « quelle version est installée sur le serveur », mais quelle version sert les pages. C'est le piège CLI/FPM évoqué plus haut.
- Quelle est la date de fin de support de sécurité de cette version ? Question de contrôle. Un professionnel doit pouvoir répondre de mémoire, ou en trente secondes.
- Quel est le périmètre exact de mon contrat sur ce point ? Demandez la clause, pas l'interprétation. « Pouvez-vous m'indiquer l'article du contrat qui traite du maintien du socle technique ? »
- Que coûterait un audit de compatibilité, et sous quel délai ? Cette question fait passer du diagnostic à l'action, sans engager de gros budget.
Les réponses qui rassurent
Une version précise, avec le numéro mineur. Une date de fin de support annoncée sans hésitation. Un renvoi à un article numéroté du contrat. Une proposition d'audit chiffrée avec un délai. Éventuellement un calendrier de migration déjà pensé, parce que le sujet était sur la table.
Les réponses qui alertent
« Tout est à jour, ne vous inquiétez pas », sans chiffre. « On regardera ça après l'été. » « De toute façon PHP 8.1 fonctionne encore très bien. » « Personne ne s'attaque à un site comme le vôtre. »
Cette dernière est la pire, parce qu'elle révèle une méconnaissance de la façon dont fonctionnent les attaques automatisées. Les robots ne choisissent pas leurs cibles. Ils balaient.
Le signal d'alarme absolu
Un prestataire incapable de vous dire dans la journée sur quelle version de PHP tourne le site qu'il maintient et facture.
Ce n'est pas une question piège, ce n'est pas une recherche complexe, c'est trois clics dans un panneau d'hébergement. Une réponse floue ou différée d'une semaine ne signifie pas qu'il ne sait pas chercher. Elle signifie qu'il ne regarde jamais.
Demander un devis comparatif sans rompre la relation
Exercice délicat, souvent redouté. Quelques principes qui fonctionnent.
Annoncez-le, ne le cachez pas. « Vu le montant, je vais faire chiffrer par un second prestataire, c'est une pratique normale de ma part sur ce type d'investissement. » Un professionnel confiant ne s'en offusque pas. Un professionnel qui s'en offusque vous apprend quelque chose sur lui.
Demandez le même périmètre aux deux, sinon vous comparerez des choux et des carottes. Et surtout, faites d'abord réaliser l'audit par un tiers indépendant. Un audit neutre, ce sont des faits partagés, et des faits partagés désamorcent la moitié des désaccords.
Éviter que le problème se reproduise dans deux ans
Parce qu'il se reproduira. PHP 8.2 sort du support fin 2026, la 8.3 fin 2027. Le même dossier reviendra sur votre bureau, à échéance connue.
Les clauses à faire ajouter au prochain contrat
Trois lignes, et le sujet est réglé pour de bon.
Un engagement de version supportée. « Le prestataire s'engage à maintenir le site sur une version de PHP bénéficiant du support de sécurité officiel. » Simple, clair, non négociable.
Un délai de bascule après annonce de fin de support. « La migration est réalisée au plus tard six mois avant la date de fin du support de sécurité. » Le délai transforme une intention en obligation.
Une répartition explicite des coûts d'évolution technologique. Inclus au forfait, facturé au tarif journalier, plafonné à X jours par an. Peu importe le choix retenu, du moment qu'il est écrit.
L'exigence de préproduction
Un environnement de test, copie conforme de la production, sur lequel on valide avant de basculer. Ça coûte quelques dizaines d'euros par mois d'hébergement supplémentaire, et un peu de rigueur méthodologique.
Ce que ça change ? Tout. Une migration testée en préproduction se déroule sans stress, sans intervention nocturne, sans « on croise les doigts ». Et le jour où quelque chose casse malgré tout, le retour arrière prend cinq minutes au lieu d'une nuit blanche.
C'est le genre de dépense qui paraît superflue jusqu'au jour où elle vous évite trois jours de boutique à l'arrêt.
Le code sur mesure est une dette, il faut le traiter comme telle
Chaque développement spécifique, chaque extension propriétaire, chaque intégration bricolée devient un point de blocage futur. Ce n'est pas une raison pour s'en priver, mais c'est une raison pour en tenir la liste.
Un inventaire simple, tenu à jour, suffit : quel composant, développé par qui, quand, quelle dépendance technique, quel niveau de criticité s'il tombe. Quand la question de la migration se posera, vous saurez immédiatement où regarder, et le chiffrage sera fiable.
La revue technique annuelle
Proposition simple : inscrivez une ligne budgétaire « revue technique » dans votre plan annuel, au même titre que le renouvellement du nom de domaine ou du certificat SSL.
Une demi-journée par an. On vérifie les versions, on liste les composants abandonnés, on regarde les échéances des douze mois à venir, on planifie. Le coût est dérisoire comparé à une migration d'urgence, et le confort mental n'a pas de prix.
Documenter et versionner
La seule assurance réellement efficace contre la facture surprise. Un dépôt Git à jour, une documentation minimale des développements spécifiques, un accès à tous les comptes techniques en votre nom.
Ce dernier point mérite qu'on insiste. Trop d'entreprises découvrent, au moment de changer de prestataire, que le nom de domaine est enregistré au nom de l'agence, que l'hébergement est sur un compte partagé, et que le code source n'existe que sur le poste d'un développeur parti depuis. Cette situation ne relève pas de la technique. Elle relève de la gouvernance, et elle se corrige en une après-midi.
Conclusion
Récapitulons ce qui se fait maintenant, dans l'ordre.
Vérifiez la version de PHP qui sert vos pages, aujourd'hui, en utilisant l'une des quatre méthodes. Vous n'avez besoin de personne. Situez ensuite votre contrat : sortez le PDF, cherchez les quatre formulations, identifiez votre régime. Puis demandez un audit de compatibilité chiffré, par écrit, avec un délai.
Trois actions, quelques heures en tout. Pas de quoi mobiliser un comité de direction.
Mais le message de fond dépasse largement PHP 8.1. La vraie question n'est pas de savoir si cette version doit être migrée, la réponse est évidente et elle était connue depuis 2021.
La vraie question, c'est : pourquoi personne ne vous a prévenu ?
Une échéance publique, annoncée quatre ans à l'avance, sur un composant critique de votre outil de travail, et aucun mail, aucun point en réunion, aucune ligne dans un rapport mensuel. Ce n'est pas un incident technique. C'est un révélateur de la façon dont votre prestation est pilotée, et il y a fort à parier que PHP n'est pas le seul sujet resté sous le tapis.
Chez FDSEO, ce type de dossier revient régulièrement, et rarement seul. L'audit technique permet d'établir des faits mesurables, opposables, indiscutables. Et l'arbitrage de la relation prestataire, mené par un tiers qui connaît le métier des deux côtés, permet le plus souvent de repartir sur une base saine plutôt que de tout casser.
Parce que dans la majorité des cas, il ne s'agit pas de changer de prestataire. Il s'agit de remettre par écrit ce qui aurait dû y figurer dès le départ.
