Vous avez reçu le code source, mais l'application ne démarre que sur le poste de l'ancien développeur. Avant d'estimer de nouvelles fonctionnalités, demandez une construction du produit depuis un environnement vierge.
Inventorier ce qui manque au dépôt
Relevez les versions nécessaires, les dépendances privées et les configurations attendues. Les secrets doivent être transmis par un canal adapté, puis renouvelés selon leur usage. Vérifiez aussi qui contrôle les comptes de publication et les services payants.
Faire essayer la procédure
La nouvelle équipe suit les instructions et note chaque intervention manuelle absente du document. Conservez les messages d'erreur utiles sans y laisser de données sensibles. Une construction réussie doit produire une version dont l'origine peut être retrouvée.
Accepter la reprise sur une preuve
Demandez une démonstration du démarrage, des tests essentiels et du déploiement sur un environnement de validation. Le compte rendu doit distinguer les éléments récupérés des dépendances toujours détenues par le prestataire sortant. Ces réserves influencent directement le coût et le calendrier de reprise.
Vérifier aussi les dépendances extérieures
Une bibliothèque publiée sur un compte privé, un certificat ou un service de messagerie peut manquer au dossier. Listez les ressources utilisées à la construction et celles nécessaires au fonctionnement. Pour chacune, identifiez le propriétaire et les démarches de transmission autorisées.
Une application peut démarrer sans envoyer ses notifications ni traiter ses tâches périodiques. Choisissez donc un parcours qui traverse ces composants. Par exemple, la création d'un dossier avec notification permet de vérifier davantage qu'un écran d'accueil. Utilisez des comptes et des données destinés à ce test.
Organiser une reprise indépendante
Demandez à une personne différente de l'auteur de la procédure de suivre les instructions. Notez les interventions nécessaires et faites les intégrer au document. Le résultat attendu comprend l'identité de la version construite et les configurations utilisées, sans exposer les secrets.
| Vérification | Résultat attendu |
|---|---|
| Installation | Versions et dépendances retrouvées |
| Construction | Artefact rattachable à un état du code |
| Démarrage | Configuration de validation connue |
| Parcours complet | Résultat métier et échanges confirmés |
| Exploitation | Tâches et alertes identifiables |
Si un composant ne peut pas être récupéré, demandez les alternatives et leurs conséquences. Un remplacement peut exiger une migration de données ou un changement d'interface. L'estimation doit montrer cette différence au lieu de la traiter comme une installation ordinaire.
Préparer le contrat de transmission
Les engagements de propriété et les droits d'utilisation doivent être examinés par les responsables compétents. Côté technique, le dossier indique les éléments disponibles et ceux encore contrôlés par le prestataire sortant. La période de transition peut être terminée sur une liste de conditions vérifiées.
Ce travail permet de commander les développements suivants sur un état connu. Sans cette base, une partie du budget de chaque nouvelle fonction risque de servir à retrouver des prérequis que la transmission aurait dû établir.
À lire aussi : Audit de reprise SaaS : vérifier les permissions avant les fonctionnalités. Présentez votre périmètre à Sky Vaults.