PHP legacy : reprise, maintenance, montées de version
Votre application PHP fonctionne. Personne ne veut y toucher.
Nous reprenons des applications PHP chargées de dette technique, nous les maintenons en condition de sécurité et nous réduisons la dette par étapes, au forfait.
Ce que vous voyez n’est que la partie émergée
Au-dessus de la ligne de flottaison
- Les clients se connectent, les commandes passent.
- La facture d’hébergement est réglée chaque mois.
- Personne ne s’est plaint cette semaine.
En dessous
- PHP 7.4, sans correctifs de sécurité depuis le 28 novembre 2022.
- Un
composer.lockque personne n’a mis à jour depuis des années. - Aucun test : chaque modification est un pari.
- Le développeur qui connaissait le code est parti.
- Un déploiement qui ne fonctionne que depuis un seul ordinateur portable.
La dette technique ne concerne pas que PHP 5. Une application Laravel ou Symfony de trois ans peut peser tout aussi lourd.
Le plus souvent, un événement force la décision
Une version arrive en fin de vie
PHP 8.2 ne recevra plus de correctifs de sécurité après le 31 décembre 2026. Laravel 12 suivra le 24 février 2027.
Votre développeur ou votre agence est parti
Le code tourne toujours, mais personne ne sait le déployer, et la documentation se résume à un vieux README.
Un questionnaire de sécurité arrive
Un client, un auditeur ou un assureur vous demande quelles versions de logiciels vous utilisez. La réponse honnête est gênante.
Votre hébergeur fait payer les anciennes versions de PHP
Certains hébergeurs facturent désormais un supplément mensuel pour maintenir des versions de PHP obsolètes.
Une due diligence se prépare
Un investisseur ou un repreneur va regarder le code. Mieux vaut savoir avant lui ce qu’il va trouver.
Désormais, c’est nous qui nous en occupons.
Nous prenons la responsabilité de l’application. Nous apprenons comment elle fonctionne, nous la protégeons par un harnais de tests, nous appliquons les correctifs et nous vous expliquons ce que nous avons modifié, et pourquoi.
- Un prix convenu pour chaque étape, fixé après avoir vu l’application.
- Des tests avant toute modification, pour que rien ne casse sans qu’on le voie.
- Des rapports en langage clair, que vous pouvez transmettre à votre direction.
- Vous échangez directement avec l’ingénieur qui fait le travail, sans intermédiaire commercial. Avec qui vous travaillez
Trois façons de commencer
Vous hésitez ? Commencez par un diagnostic.
La maintenir en sécurité
Maintenance mensuelle : mises à jour de PHP et des dépendances, supervision, sauvegarde avant chaque modification et heures d’intervention pour les corrections. L’application cesse de prendre du retard. Care commence après un Takeover.
à partir de 400 € /mois
Formules CareRéduire la dette
Montée de version de PHP et du framework au forfait, ou remplacement des parties anciennes en sprints de deux semaines, sans arrêter l’application.
Montées de version à partir de 3 000 €
Montées de versionLa reprendre
Votre développeur ou votre agence est parti. Nous récupérons les accès, rendons l’application reproductible, ajoutons des tests sur les parcours critiques et rédigeons le runbook.
à partir de 1 500 €
Takeover
Les premières semaines
Toutes les applications n’ont pas besoin de toutes les étapes. Chacune a son propre prix, convenu avant de commencer.
01
Debt Check
Vous répondez à un questionnaire et nous envoyez votre
composer.lock. Aucun accès au code. Vous recevez un rapport court : les risques par ordre de priorité, la démarche que nous recommandons et des fourchettes de prix.02
Code Audit
Sous accord de confidentialité et avec un accès en lecture seule, nous passons PHPStan, Rector et
composer audit, et nous lisons le code. Le rapport se termine par des prix fermes.03
Takeover
Nous rendons l’application modifiable sans risque : environnement reproductible, CI, tests de caractérisation et runbook.
04
Care, montée de version ou modernisation
Nous appliquons les correctifs chaque mois, nous faisons la montée de version ou nous remplaçons l’application par étapes.
Quelques organisations pour lesquelles nous avons travaillé
En direct
- Parc national des Tatras
- Poczta Polska Usługi Cyfrowe (Envelo)
- NCBR+
- Université Jagellonne
- Ernst & Young
- Onet
- Alcar
Via des agences et des partenaires
- Mercedes-Benz
- mBank
- Santander
- Orlen
- Rossmann
Derniers articles
Fin de vie de PHP 8.2 le 31 décembre 2026 : que faire
Après le 31 décembre 2026, php.net ne corrige plus PHP 8.2. Ce qui vous retient, 8.4 ou 8.5, ce qui casse, et le plan B si la date est trop proche.
Les questions que l’on nous pose en premier
Travaillez-vous uniquement sur de vieilles applications PHP 5 ?
Non. La dette s’accumule aussi dans des applications récentes : Laravel 9 ou Symfony 5 avec des paquets obsolètes, sans tests, ou sans plus personne qui connaisse le code. Nous intervenons de PHP 5 à PHP 8.5.
Notre développeur est parti. Qui maintient notre application PHP maintenant ?
Allez-vous vouloir tout réécrire ?
Rarement. Une réécriture bloque votre produit pendant des mois et fait perdre des règles métier que personne n’a jamais documentées. Nous préférons monter de version sur place ou remplacer les parties une à une. Si la réécriture est vraiment l’option la moins chère, l’audit le dira.
Avec quels frameworks travaillez-vous ?
Avec tous ceux de l’écosystème PHP, et aussi sans framework. Par exemple Symfony, Laravel, Zend Framework 1 et Laminas, CodeIgniter, CakePHP ou des frameworks maison, mais aussi des plateformes comme Sylius, quand le problème vient du PHP en dessous.
Comment traitez-vous notre code et nos accès ?
Un accord de confidentialité avant d’ouvrir le moindre fichier, d’abord un accès en lecture seule, et des clés que vous créez et pouvez révoquer. Le code, les serveurs et les comptes restent à votre nom. Le détail dans Notre méthode.
Commencez par un Debt Check
300 €, sans accès au code, rapport sous 3 jours ouvrés. Ou envoyez-nous votre composer.lock et votre version de PHP.