Consigner le point de départ
À la réception du code, conservez une copie intacte et identifiez la version livrée avant toute personnalisation. Notez la version de l’application, les manifestes de dépendances, l’état des migrations et les instructions d’installation suivies. Vérifiez quels services complémentaires font partie de la livraison et lesquels sont séparés. Excluez les secrets de l’archive et documentez plutôt les noms de leurs paramètres. Cette référence permet de distinguer un défaut initial d’une modification ultérieure et de reproduire l’environnement pour le support. Un dossier « dernière version » ne suffit pas. Chaque déploiement doit avoir un identifiant relié à son véritable code source.
Rendre les adaptations compréhensibles
Décrivez chaque personnalisation par le besoin client auquel elle répond, pas seulement par les fichiers modifiés. Lorsque c’est possible, séparez identité visuelle et configuration des modifications du fonctionnement central. Tenez un bref inventaire des extensions touchant les droits, les états de paiement ou les traitements de fond. Ces zones demandent une attention particulière à l’arrivée d’une mise à jour : deux changements raisonnables séparément peuvent être incompatibles. Avant la fusion, confrontez les évolutions du fournisseur à vos hypothèses et décidez du comportement voulu. Conservez ce choix près du code pour éviter aux futurs mainteneurs de l’inférer d’une fusion inexpliquée.
Répéter les mises à jour avec des données représentatives
Le plan doit couvrir le code et les données. Testez la version candidate dans un environnement séparé avec des données représentatives correctement protégées, plutôt que de copier sans restriction la production sur un poste de développement. Vérifiez migrations, traitements de fond, sessions et parcours opérationnels concernés. Décidez comment arrêter les tâches ou attendre leur fin avant le changement de version. Décrivez la reprise après un échec et vérifiez si une migration est réellement réversible. Restaurer un ancien code ne restaure pas automatiquement les anciennes données. Alignez les sauvegardes et une procédure de restauration répétée sur le plan de déploiement retenu.
Relier les versions aux responsabilités de support
Rédigez une note expliquant les comportements modifiés, la configuration nécessaire, les limites connues et les vérifications opérateur. Désignez la personne qui approuve le déploiement, celle qui observe ses débuts et le lieu où consigner les problèmes. Distinguez les questions sur le produit d’origine de celles liées aux adaptations, avec des preuves suffisantes dans les deux cas. Convenez du support et de l’accès aux mises à jour réellement inclus dans l’achat ; la possession du code ne les implique pas. Un produit maintenable repose sur un historique de versions et des décisions reproductibles. L’objectif est de simplifier l’évaluation suivante, sans recommencer une enquête à chaque évolution.