Votre application PHP a dix ans et plus personne ne la maintient

C’est une situation que je rencontre souvent dans les PME de la région : une application développée il y a huit ou dix ans, qui fait tourner une partie de l’activité, dont le prestataire d’origine a disparu. Elle fonctionne. Personne n’ose y toucher.

La tentation est alors de tout refaire. C’est presque toujours la mauvaise décision.

Pourquoi la réécriture complète échoue si souvent

Une application métier de dix ans contient des centaines de règles qui ne sont écrites nulle part. Le cas particulier de ce client, l’exception sur ce type de commande, la remise qui s’applique seulement le dernier jour du mois. Ces règles ne sont pas dans un cahier des charges : elles sont dans le code, et souvent elles sont la raison pour laquelle l’application est utile.

Une réécriture repart de zéro et redécouvre ces règles une par une, dans la douleur, en production. Le budget double, le projet s’étire, et pendant ce temps l’ancienne application continue de tourner sans être maintenue.

Commencer par un audit, pas par du code

Avant toute décision, il faut savoir ce qu’on a. Un audit sérieux répond à cinq questions :

• Quelle version de PHP ? En dessous de PHP 8.1, vous tournez sur une version qui ne reçoit plus de correctifs de sécurité. C’est le point le plus urgent.
• Quelles dépendances ? Les bibliothèques utilisées ont-elles des failles connues ? L’inventaire se fait automatiquement.
• Comment sont traitées les entrées utilisateur ? Injections SQL et failles XSS sont les deux problèmes que je retrouve le plus souvent dans le code de cette période.
• Où sont les mots de passe ? Stockés en clair ou avec un algorithme obsolète, c’est fréquent et c’est un incident RGPD en puissance.
• Existe-t-il des sauvegardes, et sait-on les restaurer ? La deuxième partie de la question est celle qui pose problème.

La modernisation progressive

Une fois l’urgence traitée, on avance par couches, sans jamais arrêter l’application.

D’abord la mise à niveau de PHP et des dépendances, qui apporte souvent un gain de performance immédiat et gratuit. Ensuite l’ajout de tests automatisés sur les parties les plus critiques — non pas par principe, mais parce que sans eux toute modification ultérieure est un pari.

Vient alors le découpage : on isole une fonctionnalité, on la réécrit proprement, on la branche à la place de l’ancienne. L’application reste en service pendant toute l’opération. Si un module s’avère finalement satisfaisant, on le laisse tranquille — le but n’est pas la pureté du code, c’est que l’entreprise puisse compter dessus.

Le bon moment pour ajouter de l’IA

Une application ancienne mais assainie est souvent un excellent terrain. Elle contient déjà des années de données structurées : historique de commandes, fiches clients, interventions. C’est exactement la matière dont on a besoin pour construire une prédiction utile ou un assistant de recherche interne.

Autrement dit, moderniser l’existant n’est pas seulement de la dette à rembourser. C’est ce qui rend la suite possible.