PHP / MIGRATION

Migration PHP 8.5 : montée de version sans risque

Votre projet tourne sur une version PHP en fin de support ? Fonctions supprimées, extensions incompatibles, migration commencée et abandonnée →nous reprenons le chantier là où il en est.

Audit complet, environnements Docker multi-version, tests automatisés : chaque étape est validée avant la production.

8.5 Version recommandée Sortie nov. 2025 - support actif déc. 2027
8.4 Encore maintenue Support actif déc. 2026 - sécurité déc. 2028
8.2 Sécurité seulement Support actif terminé - sécurité jusqu'en déc. 2026

Ça vous parle ?

Les situations qui déclenchent une migration

Votre version PHP n'est plus maintenue

Les failles de sécurité (CVE) s'accumulent sans correctif. PHP 5.6 est en fin de vie depuis 2018, PHP 7.4 depuis 2022, PHP 8.1 depuis décembre 2024. Chaque semaine supplémentaire sur une version obsolète augmente l'exposition de votre application.

Les dépendances bloquent la montée de version

Extensions PHP incompatibles, fonctions supprimées (mysql_*, ereg_*…), bibliothèques tierces non maintenues →le projet est coincé et impossible à faire évoluer sans une migration structurée.

Votre framework exige une version PHP plus récente

Symfony 7 requiert PHP 8.2 minimum. Laravel 11 requiert PHP 8.2. Rester sur une vieille version de PHP, c'est aussi se priver des dernières versions de vos frameworks et de leurs correctifs de sécurité.

Notre conviction

Maîtriser PHP, c'est ne jamais subir une montée de version

Un prestataire de qualité ne subit pas les montées de version →il les anticipe. PHP, Symfony, les librairies Composer : ces mises à jour sont rarement indépendantes. Elles s'enchaînent, se conditionnent mutuellement et requièrent une veille permanente pour être traitées dans le bon ordre, sans créer de régressions. C'est cette maîtrise de l'écosystème dans sa globalité qui fait la différence entre un chantier maîtrisé et une migration improvisée.

Une migration bien conduite ne perturbe pas la production : elle est préparée sur un environnement Docker dédié, validée par des tests automatisés lancés sur la version cible, et déployée progressivement. Ce qui change, c'est qu'elle nécessite un budget récurrent →traiter les mises à jour en continu coûte bien moins cher que de les laisser s'accumuler jusqu'à la crise.

PHP 8.5

Ce que la migration apporte concrètement

Migrer n'est pas seulement une question de sécurité. Chaque version majeure de PHP embarque des fonctionnalités qui simplifient le code, réduisent les dépendances et ouvrent l'accès aux dernières capacités de vos frameworks.

Sécurité continue

CVE traités dès leur publication, support officiel actif. Chaque semaine sur une version en fin de vie est une exposition supplémentaire.

JIT et performances

PHP 8 avec le compilateur JIT est jusqu'à 3× plus rapide que PHP 5.6. Le preloading OPcache réduit les temps de réponse sur toutes vos requêtes.

Langage moderne

Enums, fibers, union types, match, property hooks →les versions récentes de PHP réduisent le boilerplate et améliorent la lisibilité et la robustesse du code.

Opérateur Pipe |> (8.5)

Chaîne les transformations sans variables intermédiaires : $slug = $title |> trim(...) |> strtolower(...). Lisibilité améliorée sur les pipelines de traitement de données.

Extension URI (8.5)

Parsing natif des URLs selon RFC 3986 →fini les incohérences de parse_url(). Objets Uri manipulables avec getHost(), getPath(), withPath()…

Clone with (8.5)

Clonage d'objet avec modification de propriétés en une expression simplifie drastiquement l'écriture des objets valeur immutables.

Property hooks (8.4)

Logique get/set directement sur la propriété →plus besoin de méthodes séparées pour les cas simples. Utilisé nativement par Symfony 7.

Asymmetric visibility (8.4)

public private(set) : propriété lisible publiquement, modifiable uniquement en interne. Immutabilité partielle sans readonly total.

Enums (8.1)

Types énumérés natifs backed ou pure →fini les constantes de classe pour représenter des états finis.

Fibers (8.1)

Primitives de concurrence légère pour les frameworks asynchrones (ReactPHP, Swoole, Symfony Messenger).

json_validate() (8.3)

Valide un JSON sans le décoder →payload validé sans mémoire inutile consommée.

Readonly classes (8.2)

Le mot-clé readonly s'applique à la classe entière →toutes les propriétés deviennent readonly sans les déclarer individuellement.

Nullsafe operator ?→(8.0)

Chaîne d'accès aux propriétés/méthodes sans vérification null à chaque étape →code réduit de 30 à 50 %.

Match expression (8.0)

Alternative au switch avec retour de valeur, comparaison stricte et erreur si aucun bras ne correspond.

Méthodologie

4 étapes pour migrer sans casser la production

Pas d'improvisation. Chaque migration suit le même processus structuré, de l'audit initial jusqu'à la bascule en production.

1

Étape 1 : Audit

Cartographie des risques et dépendances

Avant d'écrire la moindre ligne, nous analysons l'état réel de votre projet : version PHP actuelle, extensions installées, fonctions dépréciées ou supprimées, couverture de tests, dette technique accumulée.

Le livrable est un rapport d'audit avec la liste des incompatibilités, une priorisation des actions et une estimation du chantier. Vous validez avant de vous engager sur la suite.

Analyse des extensions et dépendances

Inventaire de toutes les extensions PHP (native et Composer), compatibilité avec la version cible, identification des bloquants.

Dépréciations et breaking changes

Recensement exhaustif des fonctions supprimées, des changements de comportement et des suppressions entre la version actuelle et la version cible.

Rapport et estimation

Document structuré avec charge estimée, risques classifiés et recommandations sur l'ordre d'exécution. Vous savez exactement ce qui vous attend.

2

Étape 2 : Préparation

Mise en place du filet de sécurité

Avant de toucher aux dépendances, nous sécurisons la base : environnement Docker de staging dédié, pipeline CI/CD configuré sur la branche de migration, tests automatisés sur les flux critiques.

Cette étape est non négociable. Elle conditionne la réversibilité de chaque modification et la fiabilité des validations avant la mise en production.

Versions très anciennes (PHP 5.x)

Sur des projets très anciens (PHP 5.3, 5.4), il peut être plus efficace de repartir sur un nouveau projet initialisé directement sur la version cible et de réintégrer l'ancien code proprement, plutôt que de migrer pas à pas. Cette décision est prise à l'issue de l'audit en fonction du volume de code, de sa qualité et des dépendances en jeu.

Documentation structurée dès le départ

Nous formalisons chaque décision et cas particulier directement dans le code. Nos outils d'assistance IA nous aident à produire une documentation disponible immédiatement dans le dépôt →pas après.

Environnement de staging isolé

Une instance dédiée à la migration, identique à la production, où toutes les validations sont effectuées avant toute bascule.

Tests automatisés sur les flux critiques

Écriture ou renforcement des tests sur les fonctionnalités métier essentielles pour détecter les régressions dès leur apparition.

Pipeline CI/CD de migration

Chaque commit déclenche les tests automatiquement. Les régressions sont détectées immédiatement, pas à la veille de la mise en production.

Nettoyage du code mort avant migration

On élimine le code inutilisé, les extensions orphelines et les fonctions abandonnées avant d'attaquer la montée de version. Ce nettoyage est déployé en production pour que la migration parte sur une base propre.

3

Étape 3 : Exécution

Migration pas à pas, version par version

Nous progressons par itérations courtes : montée d'une version, correction des incompatibilités, validation des tests, revue. Jamais plus d'une version à la fois si plusieurs sauts sont nécessaires.

Les extensions incompatibles sont traitées au cas par cas : mise à jour, remplacement ou fork selon leur criticité dans le projet.

La force de SmartBooster

Grâce à Docker, nous pouvons lancer la suite de tests sur plusieurs versions PHP en parallèle depuis la CI. Chaque commit est validé sur la version actuelle et sur la version cible simultanément →les incompatibilités sont détectées au plus tôt, pas à la veille du déploiement.

Correction des fonctions supprimées

Traitement systématique des appels à des fonctions supprimées ou dépréciées (mysql_*, ereg_*, create_function…). Rector automatise les transformations mécaniques.

Mise à jour des extensions et librairies

Chaque dépendance est mise à jour, remplacée ou adaptée. Les extensions sans alternative sont forkées et maintenues si nécessaire.

Validation continue

Les tests sont lancés en continu sur chaque version PHP ciblée. Chaque régression est corrigée avant de passer à l'étape suivante →jamais de dette cachée.

4

Étape 4 - Déploiement

Bascule en production sans surprise

La migration production est planifiée avec une fenêtre de maintenance, une checklist de validation post-déploiement et une procédure de rollback testée en staging.

Nous restons disponibles les jours suivants pour monitorer et corriger d'éventuels comportements inattendus en conditions réelles.

Une fois la migration stabilisée, nous pouvons prendre en charge la maintenance et les évolutions de votre projet sur le long terme. Découvrez notre approche TMA (Tierce Maintenance Applicative).

Fenêtre de maintenance planifiée

La bascule est cadrée : heure, durée, équipe présente, rollback prêt. Rien n'est laissé au hasard.

Vérification post-déploiement

Check complet après la bascule : fonctionnalités, performances, logs, monitoring. L'application est validée avant de lever la maintenance.

Suivi post-migration

Surveillance active les jours suivants et prise en charge rapide de tout incident lié à la migration.

Nos bonnes pratiques

Ce qui fait la différence pour réussir nos migrations

Nous améliorons nos méthodes en continu au fil des projets.

Ces pratiques ne s'improvisent pas →elles s'acquièrent avec l'expérience et la confiance de nos clients pour réaliser des tâches la plupart du temps invisibles pour eux.

Avec les années, nous avons identifié 4 pratiques essentielles qui nous permettent de faire du travail de qualité et nous distinguent d'une bonne partie de nos concurrents.

Nettoyage du code avant de migrer

  • Fonctions PHP supprimées et code mort : Les appels à mysql_*, ereg_*, les routes inutilisées et les classes abandonnées s'accumulent au fil des ans. Nous les supprimons avant la migration →une dépendance en moins, c'est un risque de compatibilité en moins.
  • Extensions surdimensionnées : Un bundle ou une bibliothèque installée pour une tâche que quelques lignes de PDO ou de code natif suffiraient à résoudre. Quand le rapport valeur/complexité est défavorable, on supprime.
  • Fonctionnalités inutilisées : Nous analysons les données en base pour identifier ce que les utilisateurs n'utilisent plus. Moins de code à migrer, moins de dette à porter dans la prochaine version.

Automatisation pour uniformiser et gagner en qualité

  • Rector : L'outil automatise la correction des dépréciations et les refactorings mécaniques sur des centaines de fichiers : mysql_* → PDO, ${var} → {$var}, constructeurs PHP 4 → __construct(). Indispensable sur les migrations multi-versions.
  • PHPStan : L'analyse statique détecte les appels à des fonctions supprimées, les passages de null interdits et les types incohérents avant même d'exécuter le code. Montée de niveau progressive : on cible le niveau 4 minimum avant toute bascule.
  • Makefile et scripts : Chaque action d'équipe (installation, tests, déploiement) est standardisée dans un Makefile. Zéro documentation à lire pour contribuer, zéro divergence entre environnements.

Docker : changer de version PHP en une commande

  • Un environnement par version : Grâce à Docker, nous maintenons des images distinctes pour chaque version PHP ciblée. Passer de PHP 8.1 à PHP 8.4 pour lancer la suite de tests se fait en une ligne de commande sans modifier le poste de travail du développeur ni l'environnement de production.
  • Équivalence dev / staging / prod : La même image Docker tourne sur le poste du développeur, sur l'environnement de recette et en production. Il n'y a plus de 'ça marche sur ma machine' →si les tests passent localement, ils passent en staging. La migration est validée dans des conditions identiques à la production.
  • Tests matriciels multi-versions : Notre CI/CD peut lancer la suite de tests sur plusieurs versions PHP en parallèle (ex : 8.2, 8.3, 8.4) pour confirmer la compatibilité et identifier la version minimale supportée avant toute décision de déploiement.

Des développeurs responsables, pas des producteurs de code

  • Maintenance long terme dès le départ : Nos développeurs savent qu'ils maintiendront ce code en production. Ce changement de perspective transforme la façon de coder : on ne livre plus ce qui passe les tests, on livre ce qui tient dans le temps.
  • Contact direct avec les clients : Pas d'intermédiaire entre le développeur et l'utilisateur final. Comprendre le métier et les usages réels permet de dimensionner correctement les fonctionnalités et d'éviter la sur-ingénierie qui rend les migrations difficiles.
  • Maîtrise du périmètre : Un développeur qui comprend pourquoi il code telle fonctionnalité produit un code mieux structuré et mieux documenté. Les migrations futures traverseront ce code sans difficulté.

BREAKING CHANGES

Principaux changements incompatibles par version

À chaque montée de version majeure, PHP supprime les fonctions dépréciées et renforce son système de types. Ce recensement des changements majeurs permet de calibrer le chantier avant de démarrer.

  • PHP 8.4 → 8.5

    Migration courante

    Peu de BC breaks majeurs. Quelques dépréciations promues en erreurs et changements de comportement sur les extensions.

    • Opérateur Pipe (|>) : Nouvelle syntaxe →pas de BC break en soi, mais les projets qui utilisaient |> comme nom de variable ou dans des contextes non standards devront vérifier la compatibilité.
    • Extension URI : Ajout du namespace Uri\ : si votre projet définit des classes Uri dans le namespace global, des conflits de nommage peuvent apparaître.
    • array_first() / array_last() : Si votre projet définit des fonctions array_first() ou array_last() en global scope, elles entreront en conflit avec les nouvelles fonctions natives. Renommer ces fonctions avant de migrer.
  • PHP 8.3 → 8.4

    Mineure

    Peu de BC breaks, principalement des dépréciations promues en erreurs.

    • Implicit nullable parameters dépréciés : function foo(int $x = null) est déprécié →utiliser ?int $x = null. PHP 9 en fera une erreur fatale. Rector corrige automatiquement.
    • GMP, PCNTL, POSIX : Plusieurs fonctions de ces extensions ont changé de signature. PHPStan et PHPUnit détectent les appels incompatibles.
  • PHP 8.2 → 8.3

    Mineure

    Version principalement additive. Peu d'incompatibilités.

    • Typed class constants : Les constantes sans type dans les interfaces ou les classes abstraites peuvent lever des warnings si les classes filles ne respectent pas le contrat. Ajouter des types explicites est désormais recommandé.
  • PHP 8.1 → 8.2

    Attention propriétés dynamiques

    PHP 8.2 déprécie la création dynamique de propriétés : une pratique courante dans les anciens projets qui génère des notices.

    • Dynamic properties dépréciées : $obj->dynamicProp = 'value' sur une classe sans cette propriété déclarée génère une notice E_DEPRECATED. En PHP 9, ce sera une erreur fatale. Ajouter les propriétés ou l'attribut #[AllowDynamicProperties].
    • ${var} string interpolation dépréciée : La syntaxe ${variable} dans les chaînes est dépréciée au profit de {$variable}. Rector corrige automatiquement l'ensemble du code.
    • Traits : propriétés constantes : Les traits ne peuvent plus définir de constantes →les déplacer dans la classe qui utilise le trait.
  • PHP 8.0 → 8.1

    PHP 8.1

    PHP 8.1 renforce le typage et introduit des dépréciations sur le passage de null aux fonctions internes.

    • Passing null to non-nullable dépréciés : strlen(null), strtolower(null)… →passer null à une fonction qui attend string|int génère une dépréciation. En PHP 9, ce sera une TypeError. PHPStan niveau 6+ identifie tous ces appels.
    • Retour implicite null sur les fonctions void dépréciées : Les fonctions déclarées void qui retournent implicitement null émettent une dépréciation.
    • Valeurs de retour false pour les fonctions internes : Certaines fonctions qui retournaient false en cas d'échec lancent désormais une exception →à gérer explicitement.
  • PHP 7.4 → 8.0

    Refonte typage

    PHP 8.0 est une version majeure avec une refonte de la gestion des avertissements et des comportements ambigus hérités de PHP 5.

    • Warnings → TypeError / ValueError : Des opérations qui produisaient un warning silencieux en PHP 7 (passage d'un mauvais type, division par zéro) lèvent désormais des exceptions. Les tests couvrent ces cas sinon ils se révèlent en production.
    • Comparaison de types non-stricte modifiée : 0 == 'foo' retourne false en PHP 8 (true en PHP 7). L'ensemble des comparaisons lâches entre int et string a été revu →à auditer soigneusement dans les projets anciens.
    • match() et named arguments : Pas de BC break, mais ces nouvelles syntaxes peuvent entrer en conflit avec des noms de fonctions internes ou des mots-clés mal utilisés.
    • Suppression de fonctions obsolètes : create_function(), each(), get_magic_quotes_*(), mbstring.func_overload supprimés. À remplacer avant la migration.
  • PHP 5.x → 7.0

    BC break majeur

    Le saut le plus impactant de l'histoire de PHP. Zend Engine 3, suppression de fonctions entières, révision complète de la gestion des erreurs.

    • Extension mysql_* supprimée : mysql_connect(), mysql_query() et toute la famille mysql_* sont supprimées. Migrer vers PDO ou mysqli. C'est souvent le plus gros chantier sur les projets PHP 5 anciens.
    • Extension ereg supprimée : ereg(), eregi(), ereg_replace()… →remplacer par les équivalents preg_*(). Rector gère une partie des transformations mécaniques.
    • Erreurs fatales → Exceptions : Les erreurs internes du moteur PHP qui causaient une sortie abrupte lèvent désormais des exceptions Error récupérables. Cela change fondamentalement la gestion des erreurs →les catch(Exception) ne les capturaient pas avant.
    • Variables de variables dans les tableaux : $$array[key] est interprété différemment en PHP 7. Les expressions ambiguës doivent être rendues explicites avec des accolades.
    • Constructeurs PHP 4 supprimés : La méthode portant le nom de la classe comme constructeur (style PHP 4) n'est plus supportée. Remplacer par __construct().
  • PHP 5.5 → 5.6

    Mineure

    Version additive avec peu de BC breaks. Principalement des dépréciations (mysql_*, mcrypt) annoncées avant PHP 7.

    • Dépréciation de mysql_* : Les fonctions mysql_* émettent des E_DEPRECATED dès PHP 5.5. C'est le signal qu'il faut migrer vers PDO avant PHP 7.
  • PHP 5.4 → 5.5

    Mineure

    Introduction des générateurs et de finally. Peu de BC breaks.

    • Extension mysql dépréciée (officiel) : mysql_* passe en E_DEPRECATED official à partir de PHP 5.5 et sera supprimé en PHP 7.0.
    • Suppression de /e en preg_replace : L'option /e (exécution du remplacement comme code PHP) est supprimée →utiliser preg_replace_callback() à la place.

Source : Appendices de migration officiels sur php.net →liste non exhaustive, centrée sur les cas les plus fréquents en contexte applicatif.

« Les préconisations de Nicolas sur la mise en oeuvre d'une stack de développement Gitlab et sa parfaite connaissance du Framework Symfony m'ont fait gagner un temps précieux.

Toujours pro et dynamique, c'est un plaisir de travailler avec Nicolas. »

Vincent Depeyre
Vincent Depeyre
Directeur de projet | Gérant | Web | Data | Innovations

« La prestation réalisée par SmartBooster nous a pleinement satisfait. Les équipes sont très réactives, très professionnelles et de bons conseils par rapport aux demandes du client.

Je les recommande pour vos futurs projets de développement informatique. »

Arthur Porteilla
Arthur Porteilla
Chef de projet du Programme OSCAR chez ATEE

Pour aller plus loin

Approfondir votre réflexion

Maintenance et TMA

Après une migration réussie, la TMA prend le relais pour maintenir votre projet à jour en continu sans nouveau chantier à gérer.

Reprise et refonte de logiciel

Si la montée de version révèle une dette technique trop importante, une refonte partielle ou complète peut être la bonne réponse.

PHP, notre langage de référence

Historique des versions, écosystème des frameworks et nos pratiques PHP au quotidien chez SmartBooster.

FAQ

Les réponses à vos questions

Et si vous ne trouvez pas ce que vous cherchez, nous serons ravis de vous répondre en direct lors d'un rendez-vous entre humains !

Cela dépend de la taille du projet, de la qualité du code et de l'écart entre les versions. Une migration d'une version à la suivante (ex : PHP 8.1 → 8.4) prend généralement de 1 à 2 jours sur nos projets de taille standard. Le saut PHP 5.x → 7.0 ou 7.x → 8.0 est plus impactant car il supprime des fonctions entières. Nous réalisons d'abord un audit pour vous fournir une estimation avant tout engagement.

Oui, mais en procédant par étapes intermédiaires (8.0 → 8.1 → 8.x) pour traiter les suppressions progressivement. Sauter plusieurs versions génère un volume de corrections très difficile à gérer en une seule fois. Sur des projets très anciens ou de faible complexité, il peut être plus efficace de repartir sur une base propre en réintégrant l'ancien code →cette décision est prise à l'audit.

C'est un cas fréquent que nous gérons à l'audit. Selon le cas, la solution est soit d'attendre une mise à jour du mainteneur, soit de remplacer par un équivalent maintenu, soit de forker et d'assurer la compatibilité nous-mêmes. Le choix dépend de la criticité du composant dans le projet. Nous conseillons d'attendre une version PHP LTS + quelques mois pour que l'écosystème ait eu le temps de s'adapter avant de migrer.

Pas si elle est bien préparée. Nous travaillons sur un environnement de recette dédié, avec une couverture de tests activée avant toute bascule. La migration en production se fait avec une fenêtre de maintenance planifiée et une procédure de rollback testée en amont. Grâce à Docker, changer de version PHP sur l'environnement de test est une opération triviale →nous pouvons valider le comportement sur plusieurs versions avant de décider.

C'est fortement recommandé, mais pas bloquant. Si votre projet n'en a pas, nous les construisons progressivement sur les parties critiques au fil de la migration. C'est l'un des apports concrets d'une collaboration avec SmartBooster : repartir avec une base de tests solide qui facilite toutes les montées de version futures.

Vous avez un projet ?

Contactez-nous pour savoir comment nous pouvons vous aider.