01 / Application métier
02 / Du besoin au résultat
Une application métier existante était toujours utilisée en production, mais son dépôt Git historique n’était plus accessible et plusieurs modifications existaient uniquement sur le serveur. L’objectif était de reprendre le contrôle des sources et de sécuriser le projet avant de poursuivre son évolution.
Analyse de la version réellement utilisée en production, récupération des modifications absentes du dépôt, reconstruction d’une base locale fiable et assainissement de l’historique Git afin de supprimer une ancienne donnée sensible. Le projet a ensuite été transféré vers un nouveau dépôt Git privé et sécurisé.
L’application dispose désormais d’un dépôt Git maîtrisé, d’un historique assaini et d’une version de référence intégrant les modifications qui existaient uniquement en production. Le développement et les futures mises en production peuvent ainsi être réalisés à partir d’une base fiable.
03 / Détails
Faire évoluer une application métier existante nécessite avant tout de disposer d’une base fiable. Dans ce projet, l’application était toujours utilisée en production, mais le dépôt Git historique n’était plus accessible et certaines modifications avaient été réalisées directement sur le serveur au fil du temps.
Il n’était donc pas possible de simplement repartir d’une ancienne copie du projet : celle-ci pouvait être différente de la version réellement utilisée en production.
Avant d’envisager de nouvelles fonctionnalités, j’ai commencé par analyser l’environnement existant afin d’identifier précisément l’état des sources et les différences présentes sur le serveur. L’objectif était de récupérer l’existant sans perturber le fonctionnement de l’application.
L’analyse a permis d’identifier plusieurs fichiers modifiés ainsi que des fichiers qui n’étaient pas suivis par Git.
Ces éléments ont été récupérés puis comparés avec les sources disponibles afin de reconstruire une version locale correspondant réellement à l’application utilisée en production.
Cette étape était importante : repartir sur une version incomplète aurait pu entraîner la disparition de modifications nécessaires au fonctionnement de l’application lors d’une future mise en production.
Les différences identifiées ont donc été réintégrées et versionnées afin de retrouver une source de référence claire pour la suite du projet.
La reprise du projet a également mis en évidence la présence d’une ancienne donnée sensible dans l’historique Git.
Supprimer uniquement le fichier dans la version actuelle n’aurait pas été suffisant : une information supprimée peut rester accessible dans les anciens commits d’un dépôt.
J’ai donc procédé à un assainissement de l’historique Git afin de supprimer cette donnée tout en conservant les éléments nécessaires à la traçabilité du projet.
Le projet a ensuite été transféré vers un nouveau dépôt Git privé et maîtrisé, avec des règles permettant également d’éviter que certains fichiers sensibles soient ajoutés accidentellement à l’avenir.
À l’issue de cette intervention, l’application dispose désormais d’une version de référence clairement identifiée et correspondant à l’existant récupéré en production.
Les modifications qui étaient auparavant présentes uniquement sur le serveur sont maintenant versionnées, l’historique a été assaini et les sources sont centralisées dans un dépôt privé.
Cette reprise permet surtout de poursuivre plus sereinement la maintenance et le développement de l’application. Les prochaines fonctionnalités peuvent être développées et déployées à partir d’une base connue, sans risquer d’écraser des modifications historiques présentes uniquement en production.
Cette intervention illustre également une partie importante de mon travail sur les applications métier existantes : avant de modifier ou moderniser une application, il faut parfois commencer par comprendre, récupérer et sécuriser ce qui existe déjà.
04 / Socle