Vous savez maintenant que votre application PHP 7 ne passera pas en PHP 8 avec un simple réglage (nous l’expliquons dans notre article sur la migration de PHP 7 vers PHP 8). La décision de la réécrire est prise, ou presque. Reste la question que se posent la plupart des dirigeants à ce stade : concrètement, comment ça se passe, et qu’est-ce que l’entreprise y gagne au-delà de la sécurité ? Nous vous montrons ici comment nous menons ce type de chantier en PHP 8.5 chez Smart Impact.
Réécrire ne veut pas dire tout éteindre un vendredi soir
Quand on parle de réécriture, beaucoup imaginent un grand soir : l’ancienne application s’arrête, la nouvelle démarre le lundi, et on croise les doigts. C’est aussi la méthode la plus risquée, et nous la déconseillons.
Pensez plutôt à un hôtel qui se rénove étage par étage sans fermer. Les clients continuent de dormir au deuxième pendant qu’on refait le troisième. Pour une application, c’est pareil : l’ancienne et la nouvelle tournent côte à côte. Un aiguillage envoie chaque utilisateur vers l’une ou l’autre selon la partie qu’il utilise. On bascule un module, on vérifie qu’il fonctionne, puis on passe au suivant.
Les développeurs ont un nom imagé pour cette méthode : le « figuier étrangleur », une plante qui pousse autour d’un vieil arbre jusqu’à le remplacer entièrement. À la fin, l’ancienne application n’a plus rien à faire et on l’éteint, sans que personne n’ait vécu de coupure.
Les étapes du chantier
- On commence par faire l’inventaire de ce que l’application fait vraiment, avec les gens qui l’utilisent tous les jours, à la compta comme à la logistique. C’est là qu’on retrouve les règles cachées, comme l’arrondi aux 5 centimes ou la remise négociée il y a huit ans avec un gros client. On découvre aussi presque toujours des écrans que plus personne n’ouvre, et qu’on ne réécrira pas.
- On pose ensuite un filet de sécurité sur l’ancienne application. Des tests enregistrent ses résultats actuels : pour telle commande, voici la facture, voici les frais de port. La nouvelle version devra donner exactement les mêmes chiffres.
- On construit la nouvelle base, en PHP 8.5, sur un framework entretenu et un hébergement à jour.
- On migre module par module. Le premier est volontairement simple, pour roder la méthode. Les parties critiques, comme la commande ou la facturation, viennent ensuite, une fois que tout le monde a pris ses repères.
- On reprend les données sur des copies de test, et on compare les comptes : même nombre de clients, mêmes totaux de factures, mêmes soldes.
- Quand le dernier module est basculé, on éteint l’ancienne application.
À la fin de chaque module, vous validez avant de passer au suivant. Vous gardez donc la main sur le rythme et sur le budget.
Ce que vous y gagnez avec PHP 8.5
La sécurité est la raison qui déclenche le projet. Mais si on s’arrêtait là, ce serait beaucoup d’argent pour revenir au point zéro. Une réécriture bien menée rapporte plus que ça.
Quatre ans de correctifs devant vous
PHP 8.5 est sorti le 20 novembre 2025 et recevra des correctifs de sécurité jusqu’à fin 2029. Vous passez d’une application sans aucun support à quatre années de tranquillité, à condition de suivre les mises à jour.
Un code qui repère ses propres erreurs
Le PHP moderne oblige à préciser ce que contient chaque information : un prix est un nombre, un nom est un texte. Une erreur qui passait inaperçue en PHP 7 est bloquée tout de suite. PHP 8.5 va plus loin et peut signaler quand le résultat d’une opération importante est ignoré, par exemple la réponse d’une vérification de paiement que personne ne lit.
Moins de pièces externes à surveiller
PHP 8.5 sait désormais traiter les adresses web sans module extérieur. C’est un détail technique, mais il va dans le bon sens : chaque brique externe en moins, c’est une brique de moins qui risque d’être abandonnée par son auteur dans cinq ans.
Une application qui peut enfin évoluer
C’est souvent le gain le plus sous-estimé. Sur une base moderne, brancher votre application sur un nouvel ERP ou ouvrir un accès à vos revendeurs redevient un projet ordinaire. Et vous trouvez plus facilement des développeurs prêts à travailler dessus.
Pour votre équipe technique, PHP 8.5 apporte aussi l’opérateur pipe (|>), clone() avec modification de propriétés, array_first() et array_last(), l’attribut #[\NoDiscard] et les traces sur les erreurs fatales.
Pendant le chantier : ce que ça change pour vos équipes
Vos collaborateurs continuent de travailler sur l’outil qu’ils connaissent. Ils découvrent les nouvelles parties au fur et à mesure, un module à la fois, ce qui évite le choc du « tout change lundi ».
On vous demandera en revanche de désigner une personne de référence, quelqu’un qui connaît bien le métier et l’outil. C’est elle qui répond aux questions sur les règles de gestion et qui valide chaque module. Elle n’y passe pas ses journées. Mais quand elle répond en deux jours plutôt qu’en deux semaines, c’est tout le chantier qui avance plus vite.
Avant chaque bascule, les utilisateurs concernés testent la nouvelle version en parallèle de l’ancienne. Par exemple, la personne qui gère la facturation compare pendant quelques jours les factures produites par les deux versions. Si un centime diffère, on cherche pourquoi avant de basculer.
Quant à l’interface, c’est vous qui choisissez. On peut garder des écrans très proches de l’existant pour ne perturber personne, ou profiter du chantier pour simplifier ce qui agace tout le monde depuis des années.
Les risques, dits franchement
Une réécriture comporte des risques, autant le dire d’entrée. Ceux que nous rencontrons le plus souvent tiennent en cinq lignes, avec ce que nous faisons pour les contenir.
| Le risque | Comment on le limite |
|---|---|
| Oublier une règle de gestion enfouie dans l’ancien code | Inventaire avec les utilisateurs, puis comparaison automatique des résultats entre ancienne et nouvelle version |
| Le « tant qu’on y est » qui fait gonfler le projet | Les nouvelles idées vont sur une liste à part, traitée une fois la bascule terminée |
| Une erreur dans la reprise des données | Plusieurs répétitions sur des copies, avec comparaison des totaux avant la vraie bascule |
| Un budget qui dérape | Chiffrage et validation module par module : vous pouvez ajuster ou faire une pause à chaque étape |
| Devenir dépendant du prestataire | Framework standard, code documenté, et vous restez propriétaire du code |
Le deuxième risque est de loin le plus fréquent. Il part toujours d’une bonne intention, et c’est pour ça qu’il est difficile à refuser.
Ne pas se retrouver au même point dans dix ans
Si votre application en est là aujourd’hui, c’est rarement parce qu’elle était mal faite. Le plus souvent, personne ne l’a entretenue pendant des années. Le même sort attend la nouvelle si rien ne change.
Le rythme est pourtant prévisible. PHP sort une nouvelle version chaque année, en novembre, et chaque version est entretenue environ quatre ans. Les frameworks suivent un calendrier similaire : Laravel publie une version majeure par an. Une application à jour demande donc une petite intervention annuelle, comme la révision d’une voiture.
C’est ce que nous proposons à la fin de chaque réécriture : un contrat d’entretien qui prévoit la montée de version de PHP et du framework chaque année, avant que la précédente ne soit abandonnée. Quelques jours de travail par an, au lieu d’un gros chantier tous les dix ans.
Par où commencer
Une réécriture fait peur parce qu’on l’imagine comme un saut dans le vide. Menée module par module, avec vos équipes et des points de validation réguliers, elle ressemble plutôt à une rénovation bien organisée : on sait à chaque étape où on en est et combien il reste.
La première étape ne vous engage à rien d’autre qu’à y voir clair : un diagnostic de votre application, qui dit ce qu’il faut garder et ce qu’il faut reprendre en premier.
Questions fréquentes
Mon application sera-t-elle coupée pendant la réécriture ?
Non. L’ancienne et la nouvelle version tournent en parallèle, et on bascule un module à la fois. Les seules interruptions sont de courtes fenêtres de bascule, planifiées avec vous en dehors des heures de travail.
Pourquoi PHP 8.5 plutôt que PHP 8.4 ?
PHP 8.5 est la version la plus récente et celle qui sera entretenue le plus longtemps, jusqu’à fin 2029. Partir sur une version plus ancienne, c’est raccourcir d’autant votre tranquillité.
Peut-on garder nos écrans actuels ?
Oui. On peut reproduire l’interface existante pour ne pas déstabiliser les utilisateurs, ou en profiter pour la simplifier. C’est une décision à prendre au début du projet.
Qui est propriétaire du nouveau code ?
Vous. Le code est livré documenté, sur un framework standard, pour qu’un autre prestataire puisse le reprendre si besoin.
Sources
- php.net, annonce de PHP 8.5.0 (20 novembre 2025)
- php.net, versions supportées
- Phoronix, nouveautés de PHP 8.5
- Benjamin Crozat, PHP 8.5 : nouveautés et changements
