Un groupe GitLab peut réunir des années de développement tout en dépendant d’une seule personne pour les décisions administratives. Si cette personne décède ou devient indisponible, les développeurs peuvent parfois continuer à envoyer du code sans savoir qui peut gérer les accès, approuver les dépenses d’abonnement ou remplacer les identifiants de déploiement. La famille et les collègues affrontent alors différentes parties d’une même transmission inachevée.
La succession commence par un coordinateur désigné, un propriétaire suppléant dont l’accès a été testé et un inventaire des dépendances opérationnelles. Cette checklist accompagne la préparation et la première vérification après un décès. Identifiez GitLab.com ou une instance autogérée avant toute procédure administrative. Les permissions techniques constituent une partie de la continuité ; consignez séparément qui décide pour l’organisation et qui représente la succession.
1. Recenser le groupe et les responsabilités
Notez l’URL de l’instance, le chemin du groupe principal, les sous-groupes importants, les emplacements des projets et les propriétaires humains actuels. Incluez les espaces de noms personnels contenant du travail indispensable à l’organisation, mais signalez-les pour un examen distinct. Ne supposez pas que tous les dépôts créés par un fondateur appartiennent à la même entreprise ou doivent être accessibles au même successeur.
Attribuez quatre responsabilités : administration du groupe, maintenance du code, exploitation de l’infrastructure et décisions de paiement. Une personne peut cumuler les rôles, mais chacun exige un suppléant et un moyen de contact. Notez qui autorise les changements sensibles et où se trouve le journal des décisions. Demandez aux responsables de projets de repérer les dépôts, documents privés et instructions de publication absents de l’inventaire central.
2. Vérifier l’accès d’un propriétaire disponible
GitLab décrit le changement de propriétaire d’un groupe via les contrôles des membres. Le groupe doit garder au moins un membre humain avec le rôle Owner ; un robot ou un compte de service ne peut pas être son unique propriétaire. Lors de la préparation, désignez une deuxième personne de confiance et testez son accès tant que le propriétaire actuel peut aider.
Le successeur se connecte avec son propre compte et retrouve le bon groupe. Vérifiez les commandes administratives nécessaires à la transmission, au-delà de l’ouverture d’une page de projet. Consignez l’origine de ses droits et les éventuelles dépendances au fournisseur d’identité ou à d’autres paramètres de l’organisation. Conservez les éléments de récupération dans un emplacement sécurisé approuvé, avec des instructions réellement utilisables.
Une invitation réussie marque le début de la vérification. Répétez la recherche des réglages des membres, d’un dépôt critique et du contact infrastructure. Notez la date et les lacunes. Évitez de modifier la production pour prouver l’accès : examiner les commandes et accomplir une tâche autorisée sans conséquence peut confirmer la préparation sans perturber l’équipe.
3. Faire une demande ciblée en cas d’accès manquant
Si personne ne dispose des commandes requises, rassemblez l’adresse de l’instance, le chemin du groupe, les URL des projets, les identifiants connus et un contact joignable de l’organisation. Pour GitLab.com, demandez à GitLab Support quelle procédure s’applique. Pour une instance autogérée, impliquez son administrateur autorisé et les responsables de l’hébergement et de l’identité.
Expliquez l’accès manquant et le travail bloqué. Demandez au destinataire de confirmer les justificatifs nécessaires et les options disponibles. Cette checklist ne crée ni politique spéciale de transfert après décès, ni garantie de récupération, ni délai de traitement. Conservez demandes et réponses dans le journal de transmission et attribuez le suivi à une personne, plutôt que de laisser le dossier dans une boîte non surveillée.
4. Préserver davantage que le dépôt Git
Inventoriez les dépôts avec les tickets, demandes de fusion, wikis, fichiers de versions, paquets, images de conteneurs et documents importants. Déterminez ce que l’organisation est autorisée à conserver et qui doit y accéder. Un clone local peut préserver le code tout en omettant les discussions et les informations opérationnelles nécessaires à sa maintenance.
La documentation GitLab sur les exports de fichiers décrit les éléments inclus et exclus. Les variables CI/CD figurent parmi les éléments exclus des exports de projets par fichier. Consultez la documentation de votre version et de la méthode choisie plutôt que de considérer un export comme une sauvegarde opérationnelle complète.
Chaque tâche de conservation doit avoir un responsable, une destination sécurisée et une vérification. Confirmez que les fichiers s’ouvrent, notez la date de capture et les omissions. Stockez les données sensibles dans des emplacements approuvés. Si une restauration ou un import fait partie du plan, testez-le dans un environnement isolé adapté avant d’en dépendre lors d’une transmission réelle.
5. Examiner les pipelines et les identifiants
Listez les dépendances des compilations et déploiements critiques : runners, tâches planifiées, webhooks, registres externes, services cloud, publication de paquets et mécanismes de signature réellement utilisés. Identifiez les connexions liées au compte de la personne indisponible et celles gérées par l’organisation. Consignez les emplacements et les dépositaires des identifiants sans copier les secrets dans la note de continuité.
Les conseils GitLab sur les variables CI/CD recommandent de stocker les valeurs sensibles dans les paramètres plutôt que dans le fichier de configuration du pipeline. Faites examiner leur fourniture par les opérateurs autorisés. Limitez l’accès aux personnes concernées et évitez d’exposer les valeurs dans des captures, tickets ou sorties de tâches.
Préparez les identifiants de remplacement avec les opérateurs responsables. Testez une compilation représentative et, si nécessaire, un déploiement contrôlé avant la révocation ordinaire des anciennes dépendances. En présence d’indices de compromission, une intervention urgente peut primer ; documentez les tests restants. L’objectif est une séquence réfléchie avec des responsables identifiés, plutôt qu’une collection inexpliquée de jetons fonctionnels.
6. Maintenir la facturation et l’identité accessibles
Notez abonnements, renouvellements, emplacements des factures, approbateurs des paiements et contacts de facturation. Vérifiez que les communications arrivent à une adresse surveillée sous contrôle de l’organisation. Désignez quelqu’un pour décider des services à maintenir et conserver les confirmations des changements approuvés. L’administration du groupe et la responsabilité des dépenses demandent des vérifications distinctes.
Pour GitLab autogéré, recensez aussi hébergement, sauvegardes, stockage, certificats, domaines et opérateurs de l’instance. Dans les deux modèles, examinez les fournisseurs d’identité externes utilisés pour la connexion. Un accès GitLab fonctionnel ne prouve pas que quelqu’un pourra gérer le renouvellement du domaine, le contrat d’hébergement ou la configuration d’identité le mois suivant. Chaque dépendance doit avoir un successeur et une date de contrôle.
7. Achever la transmission avant le retrait ordinaire des comptes
Vérifiez tâches ouvertes, responsabilités d’approbation, intégrations et conservation autorisée avant de retirer normalement l’accès de la personne décédée. Coordonnez les modifications avec les administrateurs de sécurité et d’identité. Préservez l’attribution et l’historique utile selon les décisions de conservation de l’organisation ; n’improvisez pas une suppression générale de comptes pour faire le ménage.
Évitez de déplacer les groupes ou de modifier leurs chemins uniquement pour établir un nouvel administrateur. Si un déplacement répond à un autre besoin professionnel, examinez ses effets et préparez un plan de changement distinct. Reliez la note GitLab au plan de continuité de l’activité en ligne et réexaminez les deux après les changements de personnel ou d’infrastructure.
Prochaines étapes
Désignez un coordinateur, inventoriez les groupes et testez l’accès d’un propriétaire disponible. Signalez les permissions manquantes au support ou à l’administration de l’instance. Préservez les documents autorisés, contrôlez les dépendances des pipelines et attribuez la facturation et l’infrastructure. Terminez par une liste datée des tâches achevées et des points ouverts. Un plan répété offre aux collègues une voie concrète et réduit les décisions techniques laissées à la famille.