Une checklist vérifiable pour transmettre un produit logiciel

Définissez le responsable de reprise et les preuves de recette

Commencez par nommer l’organisation et les personnes qui exploiteront le produit après la transmission. Notez qui approuve une mise en production, administre les accès, répond aux incidents, modifie la facturation, traite une alerte de sécurité et peut arrêter un changement risqué. Décrivez les parcours utilisateur à préserver, les environnements concernés et les services volontairement exclus. Transmettre des fichiers sans responsable décisionnaire laisse les risques opérationnels au même endroit.

Transformez la fin de mission en preuves observables. Exigez registre des actifs, registre des accès, carte d’architecture, inventaire des environnements, procédure de déploiement, procédure de reprise, liste des risques connus et backlog de maintenance. Pour chaque élément, indiquez s’il a été fourni, inspecté et exercé par l’équipe destinataire. Le contrat peut traiter séparément propriété, licences, garanties et obligations. Cette checklist constate l’état opérationnel, mais ne tranche pas les questions juridiques.

Placez code et fournisseurs sous un contrôle responsable

Placez les dépôts dans l’organisation appelée à conserver le produit, selon l’accord applicable. Préservez historique Git, branches, tags, releases, tickets, pull requests, packages, sous-modules, fichiers volumineux et automatisations. Révisez les rôles au lieu de donner les droits administrateur à tout le monde. Vérifiez qu’au moins deux propriétaires autorisés peuvent restaurer l’accès et qu’aucun build critique ne dépend d’un fork personnel, d’une clé de déploiement inconnue ou d’un compte que l’entreprise ne peut administrer.

Inventoriez bureau d’enregistrement, DNS, cloud, bases, authentification, stockage, e-mail, analytics, paiement, stores mobiles, CI, supervision, support et facturation. Pour chaque fournisseur, consignez organisation propriétaire, responsable de facturation, contact de récupération, MFA, environnements, données traitées et administrateurs actuels. Invitez les personnes avec des rôles nominatifs au lieu de partager un mot de passe. Contrôlez les canaux de récupération avant de retirer l’équipe sortante.

Prouvez que build et déploiement sont reproductibles

Demandez à une personne qui n’a pas préparé la transmission de cloner le dépôt sur une machine propre et de suivre la procédure. Fixez les versions des runtimes et outils, conservez les lockfiles et listez SDK natifs, certificats ou utilitaires nécessaires. Documentez contrôles locaux, tests, commandes de build et chemin entre un commit approuvé et chaque artefact distribuable. Utilisez des fixtures ou données de démonstration sûres, jamais une copie de secrets ou de données de production.

Documentez chaque variable et secret par nom, finalité, environnement, emplacement sécurisé, équipe responsable et procédure de rotation, sans inscrire sa valeur. Vérifiez identités CI, clés de déploiement, webhooks, certificats de signature, tokens API et comptes machines. Lorsque l’équipe destinataire dispose d’un accès fonctionnel, renouvelez les identifiants connus des personnes sortantes et retirez les accès obsolètes. Exécutez un déploiement contrôlé hors production puis un rollback depuis la documentation.

Transmettez données, supervision et reprise

Cartographiez les données depuis la collecte jusqu’à la suppression. Identifiez bases principales, stockage objet, files, index de recherche, destinations analytics, exports et sous-traitants. Documentez schémas, migrations, conservation, suppression et rapprochements manuels. Notez la fréquence des sauvegardes et leur propriétaire, mais ne confondez pas tâche réussie et restauration prouvée. Restaurez des données représentatives dans un environnement contrôlé, vérifiez leur intégrité et consignez le temps, les accès et les dépendances nécessaires.

Listez tableaux de bord, journaux, sondes externes, alertes, canaux d’incident et pages d’état des fournisseurs. Chaque alerte urgente doit avoir un responsable et une réponse possible. Fournissez des runbooks pour les pannes susceptibles de toucher un parcours critique, comme fournisseur indisponible, quota épuisé, tâche échouée, release store rejetée ou traitement partiel. Organisez une simulation couvrant diagnostic, communication, atténuation, rollback et suivi, puis inscrivez chaque zone floue au registre des risques.

Faites reprendre le produit avant de fermer les accès

Utilisez un exercice pratique comme revue finale. La personne qui reprend explique l’architecture, réalise une petite modification, lance les tests, produit un artefact, déploie hors production, inspecte la télémétrie, revient en arrière et exécute une étape de reprise. L’équipe sortante peut répondre aux questions, mais ne doit pas opérer discrètement à sa place. Tout besoin d’aide non documentée devient une tâche explicite de transmission.

Clôturez avec éléments acceptés, risques ouverts, responsables et dates de revue. Séparez la transmission d’un éventuel support, garantie ou contrat de maintenance ultérieur, à faire examiner selon le cadre applicable. Retirez les accès seulement après validation des remplacements et des moyens de récupération. IVRYN se présente publiquement comme un studio produit indépendant à Paris qui conçoit, développe et exploite ses propres produits, ainsi que quelques produits pour d’autres. Ce contexte ne prouve aucune transmission particulière sans les preuves de cette checklist.

Critères de décision

Posez les mêmes questions à chaque option avant de choisir.