Reprise de logiciel existant / Reprise d'application PHP
Votre application PHP a vieilli, pas votre métier
Sans framework, sur Symfony 1, Copix, CodeIgniter, Zend, ou greffée sur WordPress : votre application PHP fait tourner l'entreprise et plus personne n'ose y toucher. Nous la reprenons telle qu'elle est et nous la faisons passer sur Symfony brique par brique, sans l'arrêter.
PHP 8.2 cesse de recevoir des correctifs de sécurité le 31 déc. 2026. Ce n'est pas une raison de tout casser, c'en est une de commencer.
Ça vous parle ?
Les situations que nous rencontrons le plus souvent
Le logiciel a quinze ans et il fait tourner l'entreprise
Écrit par une société de services locale ou un indépendant, il gère les commandes, les plannings, la facturation. Personne ne veut plus y toucher, et personne ne peut s'en passer.
Le développeur qui le connaissait est parti
Il a changé d'employeur ou de métier. Ce qu'il savait n'est écrit nulle part. Chaque modification est devenue un pari, et les modifications ont cessé.
L'hébergeur retire la version de PHP
Un courrier annonce la fin de PHP 7 sur votre serveur, ou un audit de sécurité remonte une version sans support. Vous avez une date, et pas de prestataire.
Le déroulé
3 étapes, sans arrêter le logiciel
Nous ne maintenons pas une application sur son ancien socle : la reprise mène à Symfony. Ce qui change d'un projet à l'autre, c'est le rythme de la migration, par partie ou en une seule fois.
Comprendre le projet, pour en extraire le savoir
L'audit de code établit ce qu'il y a : les modules encore utilisés, les règles métier, l'état de la base, ce qui expose le projet aujourd'hui. Nous rédigeons la documentation qui manque, nous cadrons le périmètre à reprendre, et nous ajoutons des tests sur les parcours critiques : ils vérifient que nous avons bien compris le code avant d'y toucher.
- Documentation rédigée là où il n'y en avait pas
- Périmètre cadré : ce qui se reprend, ce qui se supprime
- Tests qui valident notre lecture du code
Migrer sous Symfony, par partie ou en une fois
Symfony remplace l'ancien socle. Selon le projet, la migration se fait par partie, l'ancien et le nouveau cohabitant sur la même base de données le temps de la transition, ou en une seule fois quand le code est assez petit, ou assez abîmé, pour que la cohabitation coûte plus cher qu'elle ne rapporte. C'est l'audit qui le dit, projet par projet.
- Par partie : cohabitation sur la même base, sans bascule risquée
- En une fois : quand le périmètre est petit ou le code trop abîmé
- Ce que personne n'utilise se supprime, ne se migre pas
Éteindre l'ancien, et exploiter
Quand plus rien n'appelle l'ancien code, il s'éteint. Le projet est une application Symfony comme les autres, avec des tests, une intégration continue et un déploiement reproductible, et il entre dans notre contrat de maintenance.
- Extinction quand plus rien n'appelle l'ancien code
- Corrections et évolutions dans le même flux
- Maintenance applicative
La méthode
Brique par brique, l'ancien et le nouveau cohabitent
Presque jamais de réécriture d'un coup. Symfony prend en charge les nouvelles routes et délègue le reste à l'ancien code, sur la même base de données : le logiciel ne s'arrête jamais.
La réécriture complète reste possible quand le code est si petit ou si abîmé que la cohabitation coûterait plus cher, et c'est l'audit qui le dit.
Cohabitation
L'ancien et le nouveau tournent ensemble, sur la même base de données, sans double saisie ni bascule risquée. Pour l'utilisateur, une seule application.
Module par module
On migre d'abord ce qu'on va devoir faire évoluer. Ce qui ne bouge plus peut attendre, ou disparaître.
Trier avant de reprendre
Une fonctionnalité que personne n'utilise ne se migre pas, elle se supprime. C'est la décision au meilleur retour de toute la reprise.
Filet de sécurité
Des tests qui enregistrent le comportement actuel des parcours critiques avant d'y toucher, pour savoir immédiatement si la migration l'a changé.
Selon ce que vous avez
Ce que nous trouvons, et ce que nous gardons
Chaque socle a ses habitudes. Pour chacun : ce qu'on y trouve d'ordinaire, ce qui se garde et ce qui tombe. Sans promesse de durée : c'est l'audit qui la donne.
Vous avez une application PHP sans framework
C'est le cas le plus fréquent : un logiciel métier écrit entre 2003 et 2015, en PHP procédural ou avec un framework maison que seul son auteur connaissait. Il fait exactement ce que l'entreprise attend, parce qu'il a été ajusté pendant dix ans.
Ce qu'on y trouve
Des centaines de fichiers qui mélangent requêtes SQL, règles métier et HTML. Des règles précieuses, jamais écrites ailleurs que dans le code. Une base de données qui est le vrai actif du projet.
Ce qui se garde
La base de données, les règles métier, les écrans que les utilisateurs connaissent.
Ce qui tombe
Le code lui-même, brique par brique, au rythme où chaque module passe sur Symfony.
Vous êtes sur Symfony 1
Symfony 1 a équipé une génération de logiciels métier français entre 2007 et 2012, et beaucoup tournent encore. Son support s'est arrêté en novembre 2012. Malgré le nom, il n'a presque rien en commun avec le Symfony d'aujourd'hui : le code ne se porte pas, il se réécrit module par module.
Ce qu'on y trouve
Une structure propre, un ORM (Propel ou Doctrine 1), des formulaires et des plugins que plus personne ne maintient. Souvent un fork communautaire qui l'a fait tenir sur PHP 8, ce qui explique sa longévité. L'ORM d'aujourd'hui est Doctrine, qui n'a gardé que le nom.
Ce qui se garde
Le modèle de données, la logique métier des modèles, l'organisation en modules qui guide la migration.
Ce qui tombe
Les plugins, les formulaires, la couche de présentation, réécrits dans Symfony au fil des modules.
Vous êtes sur Copix, Jelix ou un autre framework français
Copix a été développé en France entre 2003 et 2014 et hébergé par l'ADULLACT : on le retrouve dans des applications de collectivités et d'administrations. Jelix, français lui aussi, est toujours maintenu par une petite équipe, mais rares sont ceux qui savent encore le lire. Nous avons développé sur Copix.
Ce qu'on y trouve
Une architecture en couches soignée pour l'époque, des modules bien découpés, et une communauté disparue : aucune documentation en ligne, aucun développeur à recruter.
Ce qui se garde
Le découpage en modules, souvent excellent, et tout le métier qu'ils contiennent.
Ce qui tombe
Le framework lui-même, remplacé par Symfony module par module.
Vous êtes sur CodeIgniter 2 ou 3
Très utilisé entre 2010 et 2018 pour des SaaS et des outils internes lancés par une startup ou un indépendant. CodeIgniter 3 n'est plus qu'en maintenance minimale, compatible PHP 8.1 sans garantie au-delà, et il n'existe aucun chemin automatique vers CodeIgniter 4, dont l'architecture est différente.
Ce qu'on y trouve
Un MVC simple et lisible, des contrôleurs qui font beaucoup, peu de tests, et une dépendance forte au framework pour les formulaires, les sessions et la base.
Ce qui se garde
Le modèle de données et les règles métier, faciles à isoler tant le code est lisible.
Ce qui tombe
Les contrôleurs et les vues, réécrits par module ; les helpers du framework, remplacés par ceux de Symfony.
Vous êtes sur Zend Framework 1 ou 2
Le framework des projets sérieux de 2008 à 2016, dans les PME comme dans les ETI. Zend Framework 1 n'est plus maintenu depuis septembre 2016 ; Zend Framework 2 et 3 sont devenus Laminas, que peu de projets ont suivi.
Ce qu'on y trouve
Beaucoup de configuration, une structure verbeuse mais rigoureuse, et des composants proches dans l'esprit de ceux de Symfony, ce qui rend la lecture rapide.
Ce qui se garde
Le modèle de données, les services métier, et une architecture souvent déjà découpée en modules.
Ce qui tombe
La couche de configuration et de présentation, remplacée par celle de Symfony.
Votre outil métier vit dans WordPress ou Drupal
Une agence de communication a construit votre outil métier dans le CMS qu'elle connaissait : un plugin maison, des types de contenu détournés, des formulaires et des exports, un extranet greffé sur le site vitrine. Ça a marché, puis l'outil a grossi et le CMS n'était pas fait pour lui.
Ce qu'on y trouve
Du code PHP lisible, mais un modèle de données qui range tout dans les tables du CMS. Des performances qui s'effondrent avec le volume, et une mise à jour du CMS qui casse le plugin à chaque fois.
Ce qui se garde
Le site, qui reste dans le CMS. Les données et les règles métier, qui en sortent.
Ce qui tombe
Le plugin maison, remplacé par une application Symfony qui vit à côté du site et lui parle par API.
Vous êtes sur CakePHP, Yii 1, FuelPHP, Kohana, Phalcon ou Slim
Moins répandus en France, tous morts ou dépassés : CakePHP 2 a cessé en juin 2021 et CakePHP 3 en décembre 2022, les autres avant. Ils ont tous la même forme, un routeur, des contrôleurs, un accès aux données, et nous les lisons de la même façon.
Ce qu'on y trouve
Un MVC classique, une communauté partie, et des dépendances qui ne montent plus.
Ce qui se garde
Le métier et les données, comme partout.
Ce qui tombe
Le framework, module par module.
Au-delà du code
Pour que le logiciel redevienne un actif de l'entreprise
Migrer le code ne suffit pas toujours. Un logiciel est un actif quand l'entreprise sait ce qu'il fait, décide de ce qu'il doit faire, et dispose d'une équipe capable de le faire évoluer. Quand les mêmes blocages reviennent après la reprise, la cause est ailleurs : dans la façon dont l'équipe travaille, dans ce qui n'est écrit nulle part, ou dans la distance entre ceux qui décident et ceux qui développent. Nous pouvons aller plus loin que le développement, sur ces trois terrains.
Organisation d'équipe et gestion de projet
Comment les demandes arrivent, qui les priorise, comment elles sont livrées et recettées. Un logiciel repris dans une entreprise sans méthode redevient fragile en quelques mois : nous mettons en place le flux, pas seulement le code.
- Rituels, tickets, planning
- Circuit d'une demande jusqu'en production
- Ce que nous avons fait chez Caprenov
Documentation métier et processus
Les règles que le logiciel applique sont extraites du code dès la première étape. Elles doivent ensuite vivre ailleurs que dans la tête de deux personnes : sans référentiel commun, chaque évolution se renégocie et chaque départ coûte une partie du métier.
- Glossaire et règles métier
- Processus tels qu'ils sont réellement pratiqués
- Écarts entre le logiciel et le terrain
Faire travailler ensemble métier et technique
Le métier ne comprend pas pourquoi une demande simple prend trois semaines, l'équipe technique ne comprend pas pourquoi la priorité change chaque lundi. Nous accompagnons les deux côtés à se lire, pour que les décisions se prennent avec les bonnes informations.
- Vocabulaire commun
- Ce que le métier doit savoir de la technique, et l'inverse
- Direction technique dans la durée
Votre application PHP a besoin de quelqu'un qui sache la lire ?
Dites-nous ce qu'elle fait tourner
Le socle, la version de PHP, ce qui bloque aujourd'hui. Nicolas vous dit ce qui est récupérable en l'état, ce qui presse, et par quelle brique on commencerait. Premier échange gratuit, sans engagement.
Appel de 30 min → Audit de code → Plan de reprise
GLOSSAIRE
Le vocabulaire d'une reprise PHP
Les termes que vous lirez dans l'audit et dans les échanges avec l'équipe. Chaque définition dit d'abord ce que ça change pour vous, puis ce que ça veut dire dans le code.
- PHP procédural
- Du PHP écrit comme une suite d'instructions, fichier par fichier, sans classes ni séparation entre l'accès aux données, les règles et l'affichage. C'est ainsi qu'on écrivait la plupart des logiciels métier avant 2010. Il fonctionne, mais chaque fichier doit être lu en entier pour être compris.
- Framework
- Le socle qui impose une organisation au code : où vont les écrans, les règles, l'accès aux données. Un framework vivant (Symfony) reçoit des correctifs et a des développeurs disponibles ; un framework mort (Symfony 1, Copix, Zend 1) n'a plus ni l'un ni l'autre, et c'est lui qui fige tout le projet.
- MVC
- Modèle, Vue, Contrôleur : la séparation en trois couches que presque tous les frameworks PHP ont adoptée. Les données, l'affichage, et ce qui les relie. Quand un projet la respecte, la migration est prévisible : chaque couche a son équivalent dans Symfony. Quand il la mélange, l'audit commence par la démêler.
- ORM
- La couche qui traduit les tables de la base en objets PHP, pour ne plus écrire de SQL à la main. Propel et Doctrine 1 pour les projets anciens, Doctrine pour Symfony. Le modèle de données qu'un ORM décrit est souvent la documentation la plus fiable du projet, parce qu'elle est exécutée.
- Migration brique par brique
- Remplacer un logiciel par morceaux au lieu de tout réécrire : le nouveau code prend une fonctionnalité, l'ancien garde les autres, et les deux tournent ensemble jusqu'à ce que l'ancien soit vide. Connu chez les développeurs sous le nom de strangler fig pattern. C'est ce qui permet de ne jamais arrêter le logiciel.
- Cohabitation
- L'ancien et le nouveau code installés côte à côte, sur la même base de données : Symfony reçoit toutes les requêtes et délègue à l'ancien code ce qu'il ne gère pas encore. Pour l'utilisateur, une seule application. Pour l'équipe, un périmètre qui se déplace module par module.
- Fin de support
- La date après laquelle une version de PHP ou d'un framework ne reçoit plus aucun correctif, même pour une faille connue. Ce n'est pas une panne, rien ne s'arrête ce jour-là. C'est un risque qui grandit : chaque faille publiée ensuite reste ouverte, et les hébergeurs finissent par retirer la version.
- Tests de caractérisation
- Des tests écrits avant de modifier le code, qui enregistrent ce qu'il fait aujourd'hui, juste ou faux, sur les parcours critiques. Ils ne jugent pas l'ancien code, ils le photographient. C'est le filet qui permet de migrer une brique en sachant immédiatement si le comportement a changé.
- Fork communautaire
- Une copie d'un framework abandonné, maintenue par des bénévoles pour le faire tenir sur les versions récentes de PHP. C'est ce qui a fait durer Symfony 1 plus de dix ans après sa fin de support. Utile pour gagner du temps, mais ce n'est pas un avenir : personne ne s'engage sur sa durée.
- Migration de schéma
- Une modification de la base de données écrite sous forme de script versionné, rejouable sur chaque environnement dans le même ordre. Les projets anciens modifient leurs tables à la main, sans trace. La reprise commence par remettre la base sous contrôle, table par table, au rythme des modules migrés.
D'autres termes sont définis dans notre glossaire général.
Notre savoir-faire
L'expertise qui s'adapte à votre situation
Quel que soit votre point de départ, nous avons les compétences pour vous accompagner : créer de zéro, reprendre l'existant, valider une idée ou moderniser un outil qui montre ses limites.
Développement logiciel sur mesure
Vous avez un besoin métier que les logiciels du marché ne couvrent pas. On conçoit votre outil de zéro, depuis le cahier des charges jusqu'à la mise en production.
Reprise et refonte de logiciel
Votre logiciel existant freine votre transformation numérique : trop lent, trop rigide, impossible à faire évoluer. On reprend le code et on développe un outil spécifique à votre contexte.
TMA et maintenance évolutive
Votre logiciel est en production et doit le rester : corrections, évolutions, mises à jour de sécurité. Une équipe dédiée qui le connaît et le maintient dans la durée.
Prototype et MVP
Vous avez une idée de produit ou de SaaS à valider. On construit un premier outil fonctionnel pour tester vite et à moindre coût.
Hébergement et maintenance
Votre application tourne, mais qui s'assure qu'elle reste disponible, sécurisée et à jour ? On prend en charge le déploiement et le suivi.
Transformation Excel en logiciel
Votre Excel fonctionne mais commence à montrer ses limites. On le transforme en outil métier : automatisation des tâches répétitives, collaboration en temps réel, évolutivité sans contrainte.
J'ai développé sur Copix. Quand un client m'appelle pour un logiciel écrit dessus, je sais ce que je vais trouver, et je sais que personne d'autre ne répondra.
Un vieux code PHP n'est pas un problème. C'est dix ans de règles métier que l'entreprise a payées une fois, et qu'elle n'a pas envie de payer deux fois.
« Nicolas est intervenu auprès de notre équipe de développement web et son intervention a été aussi utile que personnalisée.
Bien plus qu'un expert technique, il a donné des pistes d'évolution qui ont ouvert de nouvelles perspectives à l'équipe et donc à l'entreprise.
Nous avons donc décidé de continuer l'expérience par des interventions régulières. »
« Une belle expertise dans le développement !
Une équipe sympathique, réactive, toujours à l'écoute de nos besoins et surtout force de proposition dans la mise en place de nouvelles fonctionnalités optimales nous faciliter le quotidien.
Cela fait plus de 3 ans que SmartBooster nous accompagne, je recommande vivement! »
Pour aller plus loin
Approfondir votre réflexion
Analyse statique, dépendances, tests, architecture : le rapport qui dit ce qui se migre, ce qui se réécrit et ce qui se supprime.
Ce que chaque version de PHP a changé, et comment faire tourner un code ancien sur une version supportée sans tout réécrire.
Alors le code se reprend tel quel, sans migration de socle. C'est une autre page, et un autre parcours.
Ce qui se passe une fois l'ancien code éteint : un contrat qui couvre corrections, mises à jour et évolutions.
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 !
Presque jamais d'un coup. Une application PHP, même sans framework, se migre brique par brique : Symfony prend en charge les nouvelles routes et délègue le reste à l'ancien code, sur la même base de données. Chaque module migré remplace son équivalent ancien, et le logiciel ne s'arrête jamais. La réécriture complète reste possible quand le code est si petit ou si abîmé que la cohabitation coûterait plus cher, et l'audit le dit.
Une version sans support ne reçoit plus de correctif de sécurité : chaque faille découverte reste ouverte. Ce n'est pas une raison de tout casser, c'en est une de commencer. Nous ne maintenons pas l'ancien code sur une version plus récente de PHP : c'est la migration vers Symfony qui règle la question, et l'urgence décide de son rythme, par partie ou en une seule fois.
Probablement. Un framework PHP des années 2005 à 2015 a presque toujours la même forme : un routeur, des contrôleurs, une couche d'accès aux données, des gabarits. Nous les lisons tous, Laravel compris. Ce que nous ne faisons pas, c'est maintenir une application sur son socle d'origine, quel qu'il soit : la reprise passe par Symfony. Et si le code n'est pas en PHP, nous reprenons le projet en le reconstruisant.
Pas depuis tous. Copix et Symfony 1, nous les avons pratiqués. Pour les autres, nous savons les lire, ce qui est ce dont une reprise a besoin. Nous ne vous dirons pas que nous avons migré vingt projets CodeIgniter si ce n'est pas vrai.
Elle reste. C'est le principe de la migration brique par brique : l'ancien et le nouveau code lisent la même base. Le schéma évolue ensuite, table par table, avec des migrations de schéma versionnées, quand le module qui l'utilise est passé sur Symfony.
Ça dépend de la taille du code, de ce qui est encore utilisé, et de ce qu'on décide de ne pas reprendre. L'audit de reprise répond à cette question projet par projet, avec un plan par brique. Nous ne donnons pas de durée avant de l'avoir lu.
Vous avez un projet ?
Contactez-nous pour savoir comment nous pouvons vous aider.