Comment migrer une application PHP maison ancienne vers une application web sur-mesure
Migrer une application PHP maison ancienne vers une application web sur-mesure prend 4 à 10 semaines et environ 4 000 – 16 000 € de reprise des données, en plus du nouvel outil (5 000 à 20 000 € par lot). De nombreuses entreprises tournent sur une application web en PHP développée il y a dix ou quinze ans par un stagiaire, un freelance ou un salarié parti depuis.
Par Baptiste Lamidey, fondateur de Trinity StudioMis à jour le
Migrer une application PHP maison ancienne : repères
- Durée de migration
- 4 à 10 semaines
- Reprise des données (en plus du nouvel outil)
- 4 000 – 16 000 €
- Situation de départ
- application vieillissante
- Solutions cibles
- outil de gestion, application métier et automatisation métier
Les signes qu’il est temps de quitter une application PHP maison ancienne
De nombreuses entreprises tournent sur une application web en PHP développée il y a dix ou quinze ans par un stagiaire, un freelance ou un salarié parti depuis. Elle couvre des besoins précis que rien d'autre ne couvre, mais repose sur une version de PHP qui n'est plus maintenue, un code sans tests ni documentation, et un serveur que personne n'ose mettre à jour de peur que tout s'arrête.
Les problèmes qui s’accumulent
- La version de PHP et les bibliothèques ne reçoivent plus de correctifs de sécurité, ce qui expose les données de l'entreprise.
- Le code sans tests ni documentation rend chaque modification risquée, même pour un développeur expérimenté qui découvre le projet.
- L'hébergeur impose une mise à jour du serveur que l'application ne supporte pas, avec une date butoir qui approche.
- L'interface ancienne ne s'affiche pas correctement sur mobile et décourage les nouveaux utilisateurs de l'adopter vraiment.
Un projet comme celui-ci ? Obtenez un ordre de grandeur sous 24 h
- Réponse du fondateur, pas d’un commercial
- Budget plafonné à 20 000 €, code source livré
- Cadrage gratuit, sans engagement
Migrer sans rupture d’activité : 5 étapes
Auditer code, base et serveur
Récupérer le code, la base de données et la configuration du serveur, mesurer les failles connues, cartographier les écrans et traitements réellement utilisés, puis chiffrer les options de remise à niveau ou de reconstruction.
Sécuriser l'existant en urgence
Corriger les failles les plus graves, mettre en place des sauvegardes testées et isoler le serveur, pour gagner du temps sans exposer les données pendant la suite du projet.
Écrire les règles métier
Documenter avec les utilisateurs les règles, calculs et cas particuliers que le code applique, et constituer des jeux de tests réels pour vérifier que la nouvelle version donne les mêmes résultats.
Reconstruire par module
Reconstruire l'application module par module dans une technologie maintenue, avec tests automatiques, interface adaptée au mobile et reprise des données à chaque étape de la bascule.
Basculer puis éteindre l'ancien
Basculer les utilisateurs module par module, garder l'ancienne application en lecture seule le temps de vérifier, puis l'arrêter et archiver ses données de façon consultable.
Récupérer les données existantes
Les données d'une application PHP vivent le plus souvent dans une base MySQL ou PostgreSQL, lisible directement en SQL. Les encodages de caractères anciens, les champs mal typés et les fichiers déposés sur le serveur demandent une attention particulière pendant la reprise.
Risques à maîtriser
- Des tâches planifiées sur le serveur, invisibles dans l'interface, alimentent des exports ou des e-mails et sont oubliées à la bascule.
- Les problèmes d'encodage des caractères accentués corrompent les noms et adresses s'ils ne sont pas détectés avant la reprise.
- Attendre la date butoir de l'hébergeur pour agir oblige à une migration précipitée, sans tests ni période de recouvrement.
Questions fréquentes
Faut-il mettre à jour ou reconstruire notre application PHP ?
Cela dépend de l'état du code. Une application bien structurée peut être remise à niveau. Un code fragile, sans tests et très ancien coûte souvent moins cher à reconstruire proprement, module par module.
Peut-on garder nos données ?
Oui. La base MySQL ou PostgreSQL se lit directement, et les données sont reprises, nettoyées et contrôlées à chaque étape, avec une attention particulière aux encodages anciens.
Que faire si l'hébergeur impose une mise à jour bientôt ?
Commencer par sécuriser et isoler l'existant pour gagner du temps, puis planifier la reconstruction sans précipitation. Une migration faite dans l'urgence, sans tests, crée plus de problèmes qu'elle n'en résout.
Vers quelle solution migrer ?
Méthode et sources
Budget de migration = durée × 1 000 à 1 600 € par semaine : la reprise des données est menée à temps partiel pendant le lot de développement. Estimation indicative avant audit de l’existant.
Mise à jour : octobre 2026. Auteur : Baptiste Lamidey, fondateur de Trinity Studio. Ces valeurs sont des estimations indicatives destinées à cadrer un budget, pas un devis : un chiffrage ferme demande un cadrage du périmètre.
Recevez un chiffrage adapté à votre contexte
Cinq questions, une réponse sous 24h ouvrées, sans engagement.
