Transfert logiciel : ce qu’une nouvelle équipe doit maîtriser

Un transfert logiciel complet devrait se mesurer à la capacité d’une autre équipe à installer l’application, effectuer une modification ciblée et la déployer en test. Le code source est nécessaire. L’essai autonome révèle si les connaissances associées ont aussi été transmises.

Pour le client, la question pratique est la dépendance à une personne ou à un ordinateur précis. Une archive téléchargeable n’y répond pas.

Un environnement vierge révèle les lacunes

Dans un exemple fictif, la nouvelle équipe reçoit la version approuvée R-1 d’un portail de commande. Tout démarre sur l’ancien ordinateur. Sur un système de test vierge, il manque pourtant la version exacte de l’environnement d’exécution, l’initialisation d’une base vide et le sens de deux variables d’environnement. Le code est arrivé ; une partie de l’installation reste floue.

Une longue documentation générale peut laisser le même manque. Une procédure utile permet à la nouvelle équipe de suivre les étapes réellement nécessaires. Les principes Twelve-Factor séparent configuration variable et code, et privilégient des environnements de développement et de production similaires. Ils donnent une orientation, pas un dossier de transfert complet pour toute technologie.

Une petite modification comme preuve

Pour l’essai, R-1 est installée avec des dépendances définies. L’équipe crée une base de test vide, utilise des identifiants artificiels et termine la commande de test T-31. Les clés de production n’ont pas leur place dans le dépôt ou la procédure.

Elle remplace ensuite le libellé « Référence » par « Référence client », reconstruit l’application et la déploie en test. Enfin, elle revient à la version précédente. Cette petite intervention vérifie que installation, modification, déploiement et retour arrière sont compris ensemble. Elle ne prouve pas la maîtrise de toute fonction future.

Si l’ancienne équipe doit préciser des étapes manquantes, ajoutez-les au transfert puis réessayez. Une explication orale résout l’instant ; la lacune n’est durablement comblée que si l’information reste disponible pour le prochain essai.

Quand un périmètre réduit suffit

Pour une extension limitée d’une plateforme déjà exploitée ensemble, remettre le code modifié peut être une étape intermédiaire utile. Recréer tout un environnement d’exploitation pourrait être disproportionné. Il faut alors préciser quelles connaissances et quels accès existent déjà, et qui en reste responsable.

Les services simulés sont aussi légitimes lorsque l’essai ne doit pas utiliser de vraies connexions. Indiquez ce qui n’a donc pas été testé. Un paiement simulé ne prouve pas une connexion de production fonctionnelle.

Pour un changement complet d’équipe, l’essai autonome est le critère le plus solide. Il révèle le travail restant avant que l’ancien interlocuteur ne soit plus disponible. Le compte rendu de recette devrait nommer la version, le parcours terminé et les dépendances encore ouvertes.

Sources

• The Twelve-Factor App: Config

• The Twelve-Factor App: Dev/prod parity