Mettre à niveau PHP et votre framework, au forfait.
PHP 8.2 ne recevra plus de correctifs de sécurité après le 31 décembre 2026. Nous faisons passer votre application sur des versions de PHP et de framework maintenues, en posant les tests d’abord. Vous connaissez le prix avant que nous commencions.
Quand une montée de version s’impose
Votre version de PHP est en fin de vie, ou presque
PHP 8.1 n’a plus de support de sécurité depuis le 31 décembre 2025. PHP 8.2 suivra le 31 décembre 2026.
Votre framework n’est plus maintenu
Les correctifs de sécurité de Laravel 11 ont pris fin le 12 mars 2026. Les corrections de bugs de Symfony 6.4 s’arrêtent en novembre 2026.
Composer refuse de suivre
Les paquets dont vous avez besoin exigent un PHP plus récent, et certains de ceux que vous utilisez sont abandonnés.
Votre hébergeur facture un supplément
Certains hébergeurs facturent un forfait mensuel pour les anciennes versions de PHP. La montée de version supprime ce coût.
Montées de version courantes
| De | Vers | Comment |
|---|---|---|
| PHP 7.x, 8.0–8.2 | PHP 8.4 ou 8.5 | Rector pour les changements mécaniques, PHPStan pour repérer ce qui reste, un ingénieur pour le reste. |
| Laravel 5–11 | Laravel actuel | Une version majeure à la fois, avec les tests relancés après chaque étape. |
| Symfony 3–7.3 | Symfony 7.4 LTS | D’abord vider le journal des dépréciations, puis une LTS à la fois (6.4 comme étape intermédiaire). |
| Zend Framework 1 | zf1-future sur un PHP plus récent, ou migration progressive vers Symfony | zf1-future est un fork communautaire, testé jusqu’à PHP 8.2, version dont le support s’arrête le 31 décembre 2026. La migration progressive est souvent la voie la plus sûre. |
| Laminas MVC | Mezzio ou Symfony | Laminas MVC ne reçoit plus que des correctifs de sécurité jusqu’au 31 décembre 2028, et ne prendra pas en charge PHP 8.5. |
| CodeIgniter 3 | CodeIgniter 4 | Plus proche d’une réécriture que d’une montée de version : nous migrons donc par étapes. |
| CakePHP 2–4 | CakePHP 5 | D’abord les outils de migration de CakePHP, puis les corrections manuelles. |
Déroulement d’une montée de version
01
Code Audit
Nous mesurons l’écart : PHPStan, exécution à blanc de Rector (dry run),
composer outdatedetcomposer audit, plus la lecture du code.02
Prix ferme
Vous recevez le périmètre, les étapes, le planning et un prix unique. Tout ce qui sort du périmètre fait l’objet d’un devis séparé, avant d’être réalisé.
03
Filet de sécurité
Des tests de caractérisation sur les parcours critiques, issus du Takeover ou ajoutés à ce moment-là, et une CI qui les exécute à chaque modification.
04
Petits pas
Une version à la fois. Chaque étape est une merge request que vous pouvez relire, et les tests doivent passer avant d’aller plus loin.
05
Mise en production et surveillance
Nous déployons avec un plan de retour arrière et suivons la supervision de près dans les jours qui suivent.
Ce que vous recevez
Code mis à niveau
Dans votre dépôt, sur des versions de PHP et de framework maintenues.
Rapport de montée de version
Ce qui a changé, ce qui a été remplacé ou supprimé, et les points à surveiller.
Rapport sur les dépendances
Chaque paquet Composer : mis à jour, remplacé ou conservé, et pourquoi.
Tests et CI
Les tests sur lesquels nous nous sommes appuyés, intégrés à votre pipeline.
Baseline PHPStan
Le niveau atteint aujourd’hui par le code, pour qu’il ne régresse pas.
Runbook à jour
Nouvelles versions, nouvelles commandes, mêmes étapes pour votre équipe.
Délais et prix
| S | M | L | |
|---|---|---|---|
| Prix | à partir de 3 000 € | à partir de 6 000 € | sur devis après le Code Audit |
Rector ne suffit-il pas ?
Rector et Laravel Shift font une bonne partie du travail mécanique, et nous utilisons Rector sur chaque montée de version.
Ce qu’un outil ne fait pas : découvrir quelle page votre plus gros client utilise tous les lundis, la tester avant et après, et être encore là quand un comportement étrange apparaît deux semaines plus tard. Cette partie-là, c’est notre travail. Ensuite, Care maintient l’application à jour, pour que la dette ne revienne pas.
Questions sur les montées de version
Fin de vie de PHP 8.2 : que se passe-t-il concrètement le 31 décembre 2026 ?
Rien de visible. L’application continue de tourner. Mais à partir de cette date, les failles de sécurité découvertes dans PHP 8.2 ne sont plus corrigées par le projet PHP, et les scanners de sécurité comme les questionnaires signalent la version comme non maintenue. Si la montée de version ne peut pas être faite d’ici là, un support étendu peut encore corriger PHP lui-même pendant un temps.
Pouvons-nous passer directement de Laravel 8 à la version actuelle ?
Dans le code, nous passons par chaque version majeure, car chaque guide de migration part de la version précédente. Pour vous, c’est un seul projet, avec un seul prix.
L’application sera-t-elle indisponible ?
Pas d’interruption prévue au-delà d’un déploiement normal. Nous préparons la montée de version sur une branche et la livrons comme n’importe quelle autre modification.
Mettez-vous aussi le serveur à niveau ?
Si c’est dans le périmètre et que nous avons les accès, oui : PHP-FPM, extensions, images Docker. Si votre hébergeur gère le serveur, nous coordonnons la bascule avec lui.
PHP 8.4 ou PHP 8.5 ?
PHP 8.5 reçoit des correctifs de sécurité jusqu’au 31 décembre 2029, PHP 8.4 jusqu’au 31 décembre 2028. Nous recommandons en général la version la plus récente que toutes vos dépendances prennent en charge.
Découvrez ce qu’implique votre montée de version
Envoyez-nous votre composer.lock et votre version de PHP : un lien vers le dépôt, ou le fichier en pièce jointe d’un e-mail. Nous répondons avec la prochaine étape et, quand c’est possible, une fourchette de prix.