Checklist de transfert : ce que vous devez posséder quand l’agence s’en va

Un schéma revient quand des entreprises nous demandent de reprendre un produit existant : juridiquement elles possèdent le code, et pourtant elles ne peuvent pas livrer. Le dépôt est là. Le compte de déploiement appartient à quelqu’un qui est parti. Le domaine est enregistré au nom d’une agence. Personne ne sait quelles variables d’environnement la production réclame.

C’est rarement de la mauvaise foi. C’est généralement que personne n’a écrit ce qui se trouvait dans la tête de quelqu’un. Mais l’effet est le même, et le moment de l’empêcher est avant le début du projet, pas à la fin.

Ce que posséder signifie réellement

Posséder un logiciel, c’est cinq choses, et le code n’est que la première :

1. Vous avez le code, avec son historique.
2. Vous pouvez le construire et l’exécuter depuis une machine vierge.
3. Vous pouvez déployer sans demander à personne.
4. Vous contrôlez les comptes et domaines dont il dépend.
5. Vous comprenez les décisions assez pour le modifier.

S’il en manque une, vous n’avez pas un produit : vous avez une dépendance.

La liste

Code

• Le dépôt est dans votre organisation, pas sur un compte personnel ni celui de l’agence.
• Historique complet, pas un unique commit écrasé. L’historique est de la documentation.
• Toutes les branches et étiquettes, y compris celle actuellement en production.
• Les fichiers sources de design (Figma ou équivalent) dans votre espace, avec les polices et licences notées.

Construire et exécuter

• Un README qui fonctionne sur une machine vierge. Le test est littéral : quelqu’un qui n’a jamais vu le projet le suit et lance l’application. S’il casse à l’étape quatre, ce n’est pas terminé.
• Versions des dépendances figées, avec le fichier de verrouillage dans le dépôt.
• .env.example listant chaque variable, son rôle et où l’obtenir.
• Comment lancer les tests, et à quoi ressemble une exécution réussie.

Déployer

• Vous pouvez déployer en production vous-mêmes, et l’avez réellement fait une fois avant le transfert. Pas « on pourrait si besoin ». Fait.
• La configuration de la chaîne de déploiement est dans le dépôt, pas cliquée dans un tableau de bord invisible.
• Vous savez faire un retour arrière, et l’avez essayé.
• Les migrations de base de données sont documentées, y compris leur exécution en production.

Comptes et domaines

La catégorie qui cause le plus de douleur, car chaque élément est petit et facile à oublier :

• Bureau d’enregistrement du domaine à votre nom, avec un renouvellement sur une carte qui n’expire pas avec le contrat de quelqu’un.
• DNS, avec la trace de ce à quoi sert chaque enregistrement.
• Hébergement, cloud, CDN.
• App Store et Play Console sous votre organisation, avec les clés de signature et certificats. Perdre la clé de signature Android signifie ne plus jamais pouvoir mettre cette fiche à jour.
• Messagerie, prestataire d’e-mails transactionnels, et les enregistrements DNS qui l’authentifient.
• Suivi des erreurs, analytique, prestataire de paiement.
• Chaque clé d’API tierce, et le compte sur lequel elle est facturée.

Pour chacun : le propriétaire est-il une adresse contrôlée par votre société ? Pas l’e-mail professionnel d’une personne. Une adresse partagée ou de fonction qui survit à un départ.

Compréhension

• Une brève note d’architecture : quelles sont les pièces et comment circulent les requêtes.
• Des enregistrements de décisions pour les choix qui, sans cela, laisseraient perplexe le prochain ingénieur. Pourquoi cette base de données. Pourquoi pas ce framework. Pourquoi ce contournement bizarre existe.
• Un manuel d’exploitation : ce qui casse, ce que signifient les alertes, quoi faire à deux heures du matin.
• Les problèmes connus et les raccourcis assumés, écrits honnêtement.

Les enregistrements de décisions sont le document de plus grande valeur que personne n’écrit. Le code montre ce qui a été fait. Seule une décision écrite montre ce qui a été écarté et pourquoi, et c’est cela qui empêche l’équipe suivante de répéter une erreur que vous avez déjà payée.

Vérifiez avant la fin de la relation

Un document de transfert est une affirmation. Vérifiez-la tant que ceux qui l’ont rédigée sont encore joignables.

Deux exercices, tous deux valant une après-midi :

• Le test de la machine vierge. Quelqu’un qui n’a pas travaillé sur le projet prend un portable neuf, suit le README et le lance en local. Chaque endroit où il bloque est un défaut de documentation. Corrigez-le sur place.
• Le test de déploiement. Votre équipe fait une modification triviale, la met en production, la vérifie et la retire. Si une seule étape nécessite l’agence, le transfert est incomplet.

Faites cela avant le paiement final, pas après. Ce n’est pas de la méfiance ; c’est le seul moment où tout le monde est encore disponible et motivé.

Mettez-le en place dès le départ

Presque tout ceci est trivial le premier jour et coûteux au neuvième mois. Au lancement :

• Créez les comptes dans votre organisation et invitez-y l’agence, plutôt que l’inverse.
• Enregistrez le domaine vous-mêmes.
• Utilisez des adresses de fonction pour la propriété des comptes dès le début.
• Convenez que la documentation fait partie de « terminé », et n’est pas une tâche de clôture.

Ainsi organisé, le transfert cesse d’être un événement. Il devient la révocation de quelques accès, parce que tout était déjà à vous.

Quoi demander avant de signer

Trois questions à poser à toute agence, la nôtre comprise :

• À quel nom seront les comptes ? Au vôtre, dès le départ, est la seule bonne réponse.
• Pourrons-nous déployer sans vous ? Et pouvons-nous le prouver pendant le projet plutôt qu’après ?
• Que se passe-t-il si nous arrêtons de travailler ensemble au troisième mois ? Une réponse honnête décrit un processus. Une réponse floue est un avertissement.

Une agence confiante dans son travail n’a aucune raison de retenir quoi que ce soit. Si ces réponses vous mettent mal à l’aise, c’est la chose la plus utile que vous apprendrez de toute la conversation commerciale.