Préparez la reprise d’un logiciel métier : code, comptes, déploiement, données et support. Vérifiez le transfert avec une remise en service de test.
Votre prestataire vous a remis une archive du code. Pour reprendre la maintenance, la nouvelle équipe doit encore comprendre comment construire l’application, où elle s’exécute et qui contrôle ses comptes. Une livraison de fichiers laisse ces questions ouvertes si aucun exercice de reprise n’a eu lieu.
Le dossier de transfert peut rester simple pour une petite application. Il doit cependant permettre à une personne autorisée, qui ne connaît pas le projet, de réaliser les opérations d’exploitation prévues. C’est ce que l’exercice final doit vérifier.
Inventorier les comptes et leur responsable
Listez le dépôt de code, l’hébergement, le domaine et les services externes. Pour chacun, identifiez le titulaire du compte, les administrateurs et le contact qui reçoit les alertes de facturation. Une application peut dépendre d’un compte créé avec l’adresse personnelle d’un ancien intervenant.
Vérifiez la procédure d’accès avant le départ du prestataire. Le transfert doit employer les mécanismes du service et respecter les droits convenus. Les mots de passe et clés ne doivent pas circuler dans un document partagé sans protection ; prévoyez leur remise et leur renouvellement dans le dispositif de gestion des secrets de l’entreprise.
Les droits sur le code et les licences dépendent des contrats et des composants utilisés. Faites confirmer le périmètre transmis par les personnes responsables. La présence d’un dépôt Git ne permet pas, à elle seule, de conclure que tous les droits ont été cédés.
Retrouver la version réellement en production
Demandez la référence du code déployé et les versions des dépendances. Une branche appelée « final » ne suffit pas si personne ne sait quelle révision a servi à la dernière livraison.
Le dossier doit expliquer comment construire cette version et où trouver sa configuration. Distinguez les paramètres documentables des secrets. Incluez les prérequis qui ne figurent pas dans le dépôt, comme un service de messagerie ou une base administrée par un autre fournisseur.
| Élément à remettre | Vérification de reprise |
|---|---|
| Dépôt et référence de version | Retrouver le code de la version active |
| Procédure de construction | Produire l’application depuis un environnement préparé |
| Configuration d’exploitation | Identifier les paramètres et leurs responsables |
| Procédure de déploiement | Installer une version en test |
| Sauvegardes et restauration | Récupérer les données prévues |
| Liste des services externes | Tester les connexions autorisées |
| Incidents connus | Comprendre les limites déjà identifiées |
Faire travailler l’équipe qui reprend
Organisez un exercice en préproduction. La nouvelle équipe prépare l’environnement, construit l’application et la déploie à partir du dossier. Le prestataire sortant répond aux questions, mais l’exercice doit faire apparaître les étapes absentes de la documentation.
Utilisez des données de test et bloquez les effets externes indésirables. Vérifiez un parcours métier complet avec un compte utilisateur ordinaire. Le démarrage du serveur prouve seulement une partie du fonctionnement.
Ajoutez un test de restauration des sauvegardes. Cela permet d’identifier les fichiers ou configurations qui manquent avant qu’un incident réel impose la reprise. Consignez les obstacles et refaites les étapes corrigées.
Définir ce que la maintenance couvre
Écrivez les horaires de prise en charge, les canaux de signalement et les personnes autorisées à demander une intervention. Distinguez la correction d’un défaut, une mise à jour technique et une nouvelle fonctionnalité. Chacune peut relever d’un budget ou d’un processus différent selon l’accord retenu.
Précisez qui surveille les alertes et qui décide d’interrompre un service en cas d’incident. Un abonnement de maintenance ne signifie pas automatiquement une surveillance permanente. Les responsabilités entre votre équipe, l’hébergeur et le mainteneur doivent pouvoir être comprises sans interprétation.
Pour les changements de code, conservez des critères communs de livraison. La Definition of Done présentée par Atlassian donne un cadre pour formaliser des vérifications partagées. Adaptez-le aux opérations réellement couvertes par la maintenance.
Décider ce qui doit être modernisé
La reprise peut révéler des composants vieillissants. Classez-les selon leur impact sur l’exploitation et la capacité à intervenir. Il n’est pas nécessaire de transformer simultanément tout le logiciel pour commencer à documenter et surveiller son fonctionnement.
Google Cloud décrit une approche progressive de modernisation des applications. Pour votre dossier, traduisez cette logique en un backlog de changements justifiés, avec leurs dépendances et une méthode de retour arrière. Une refonte complète demande un cadrage distinct.
Pour organiser une reprise dans le cadre de notre offre de développement logiciel au Maroc, contactez Sky Vaults avec la technologie utilisée, les accès disponibles et les difficultés actuelles. Vous pouvez préparer cet échange sans transmettre de secrets ni de données clients.