Des secrets dans le dépôt Git
Le fichier de configuration de production, avec le mot de passe de la base et des clés d’API, était versionné depuis des années.
Cas composite · Symfony
De l’audit à la reprise d’une application Symfony
Une PME exploite un extranet Symfony dont le prestataire d’origine n’est plus disponible. Chaque évolution est jugée risquée, plus personne ne veut toucher au code, et une réécriture complète est envisagée.
Contexte
Ce cas est composite : il réunit des situations que nous rencontrons régulièrement lors des reprises menées après un audit. Il ne décrit pas un client unique.
L’application est un extranet métier d’environ 120 000 lignes de PHP, en production depuis 7 ans, développé par deux prestataires successifs. Elle tourne sur des versions de Symfony et de PHP qui ne reçoivent plus de correctifs de sécurité. C’est l’application décrite dans notre exemple de rapport d’audit Symfony.
Ce que l’audit a montré
29 constats, dont 3 critiques. La base de code est saine dans son ensemble : la réécriture envisagée par le client n’est pas justifiée.
Un export non cloisonné
En modifiant un paramètre de l’adresse, un utilisateur pouvait exporter les dossiers d’une autre agence.
Un socle hors support de sécurité
Des versions de Symfony et de PHP hors support, avec 14 dépendances touchées par des vulnérabilités publiées, dont 3 classées élevées.
Un plan sur trois mois
Charge estimée par l’audit : 25 à 35 jours, répartis sur 3 mois.
Les actions P1
Secrets sortis du dépôt et renouvelés, contrôle d’accès corrigé, tests fonctionnels sur les 8 parcours critiques.
Les actions P2
Montée de version par paliers, d’une version à support long à la suivante, remplacement des paquets abandonnés, requêtes optimisées, déploiement reproductible, sauvegardes testées.
Contrat de maintenance
Traitement progressif des actions P3, dont l’extraction de la logique métier des contrôleurs, au fil des évolutions.
Pourquoi cet ordre
Les failles de sécurité passent en premier : elles exposent la production dès aujourd’hui et se corrigent en quelques jours. Les tests viennent ensuite, parce qu’une montée de version sans tests sur les parcours critiques revient à découvrir les régressions en production.
La montée de version se fait par paliers, d’une version à support long à la suivante. Chaque étape a ses dépréciations, plus simples à traiter une par une qu’en un seul saut de trois versions.
Résultat
Un socle de nouveau maintenu, des évolutions de nouveau chiffrables, et un budget très inférieur à celui d’une réécriture.
Stack
Questions fréquentes
Que faire quand le prestataire d’origine n’est plus disponible ?
Commencer par un audit. Il établit ce qui tient, ce qui menace la production et ce que coûtera la remise à niveau, même sans documentation ni accès complets. Le rapport précise ce qui n’a pas pu être vérifié.
Pourquoi ne pas monter directement à la dernière version de Symfony ?
Parce que chaque version majeure retire des fonctions annoncées comme dépréciées dans la précédente. Monter par paliers, de version à support long en version à support long, permet de traiter ces changements étape par étape et de tester l’application entre chaque.
Pourquoi écrire des tests avant la montée de version ?
Sans tests sur les parcours critiques, une régression introduite par la montée de version n’est découverte qu’en production. Les tests transforment chaque palier en étape vérifiable.
Une réécriture n’est-elle pas plus simple ?
Elle repart de zéro, avec le risque d’oublier des règles métier enfouies dans le code et un budget bien plus élevé. Quand l’audit montre une base saine, la remise à niveau par paliers est plus sûre et moins chère.
Une application Symfony que plus personne ne veut toucher ?
L’audit vous dit si elle se remet à niveau ou s’il faut la réécrire, et ce que coûte chaque option. Voir aussi notre approche de la reprise de projet notre guide sur la mise à jour PHP obligatoire et comment mettre à jour une ancienne version de Symfony.