Services
Maintenance, refactoring, mises à niveau et évolution pragmatique des applications PHP existantes.
Une application PHP développée sur la durée porte souvent les règles dont l’entreprise dépend : prix, commandes, factures, droits, rapports, exports comptables et intégrations. Son âge justifie une évaluation des risques, pas l’abandon automatique du système. Un framework récent peut aussi présenter des limites floues ou manquer de tests, tandis qu’un système ancien peut gérer des workflows prévisibles et des données utilisées quotidiennement.
GiSoft commence par déterminer ce qui fonctionne, ce qui échoue, quels processus sont critiques et ce dont l’entreprise a besoin ensuite. La décision peut alors être de conserver, stabiliser, refactorer, moderniser ou remplacer une partie ciblée.
Une première revue cartographie les workflows importants, la responsabilité des données, les comptes et droits utilisateurs, les dépendances, intégrations, traitements en arrière-plan, le déploiement et les angles morts opérationnels. La stabilisation peut passer avant un vaste changement lorsque les erreurs disparaissent dans les logs, les relances créent des doublons, les mises en production sont risquées ou que la récupération d’un import en échec est floue.
Les tests de caractérisation protègent un comportement métier connu avant une modification d’implémentation. Ils peuvent décrire le calcul d’un prix, la création d’une commande, les règles de facturation, le statut client ou le contrôle d’accès. Il ne s’agit pas de tester chaque méthode legacy, mais de protéger les workflows dont l’erreur aurait une conséquence importante.
Les applications Symfony 1.x utilisent souvent modules, actions, templates, helpers de formulaires, Propel ou les premières versions de Doctrine, cron jobs et jQuery. Le passage à Symfony moderne n’est généralement pas une mise à niveau mécanique, version après version : routing, authentification, formulaires, conception des services, ORM, configuration et dépendances peuvent exiger des décisions séparées. Une démarche contrôlée peut d’abord isoler la logique métier et les intégrations risquées, puis introduire des composants Symfony modernes là où cela se justifie.
Dans les anciens Laravel, les règles métier peuvent être réparties entre contrôleurs, modèles Eloquent, services et requêtes HTTP, et les jobs avoir des règles de relance floues. Le travail utile consiste à clarifier les frontières et la validation, protéger les comportements importants et mettre à niveau les paquets ainsi que le runtime par étapes compatibles.
Zend Framework 1, Zend Framework 2/3 et Laminas demandent chacun une évaluation de compatibilité propre. Yii, Yii 2, les frameworks maison et le PHP simple avec des fichiers include exigent la même discipline : comprendre les points d’entrée, l’état global, les dépendances et les règles métier cachées dans le code. Il n’existe pas de trajectoire de migration universelle.
Le SQL direct n’est pas un défaut par principe. Il peut être pertinent pour le reporting, les opérations sensibles aux performances ou un modèle de données établi. Il devient risqué lorsque des règles critiques ou des limites entre organisations sont copiées de manière incohérente, que la responsabilité des données est floue ou que les changements ne sont pas testables. Doctrine et les autres ORM doivent servir l’application, sans être imposés partout.
Avant de modifier une base, il faut déterminer quel système détient chaque valeur importante et comment anciennes et nouvelles versions peuvent coexister. Une migration de données doit, lorsque c’est praticable, être incrémentale, testée sur des données historiques et suivie d’une vérification. Des modifications destructives et des conversions irréversibles exigent un plan de récupération : revenir au code précédent ne répare pas automatiquement les données modifiées.
Les systèmes legacy dépendent souvent de SOAP, REST, XML, CSV, SFTP, cron jobs, files de messages et prestataires externes. Ces détails doivent rester derrière des frontières d’intégration. Validez les entrées et sorties, limitez les relances et rendez les tâches en échec visibles. Un timeout ne prouve pas qu’une opération externe a échoué ; les cas incertains demandent souvent un rapprochement plutôt qu’une répétition aveugle.
Comptes existants, authentification et autorisation doivent être revus avant l’ajout de nouvelles fonctions. Vérification des droits côté serveur, séparation des organisations, protection des secrets et logs raisonnables restent nécessaires quel que soit l’âge du framework. Une interface rendue côté serveur ou jQuery peut rester adaptée si elle aide l’utilisateur ; une API moderne ou un nouveau frontend sont des options, pas des obligations.
Les mises à niveau du runtime PHP exigent des dépendances compatibles, une revue de Composer, des contrôles de configuration et la vérification des workers, tâches planifiées et scripts de déploiement. La supervision doit relier signaux techniques et effets métier : traitements échoués, exports retardés, écarts de paiement ou de facture et récupération manuelle.
Une approche progressive est souvent plus sûre lorsqu’un workflow utile peut être protégé et modifié à une frontière : intégration de paiement, reporting, authentification, API client ou tâche de fond. Une réécriture complète peut se justifier si le système actuel ne répond pas en sécurité à des besoins essentiels, mais elle comporte ses propres risques de migration et de continuité.
GiSoft accompagne les applications PHP établies avec un plan fondé sur les faits : comprendre le processus, protéger le comportement critique, réduire le risque opérationnel immédiat et rendre la prochaine évolution maîtrisable. La bonne voie dépend du runtime, du framework, des données et des intégrations. L’objectif est une continuité pratique et un progrès utile, pas la technologie pour elle-même.
