Récupérer l’accès GitHub et d’hébergement quand un freelance en est le propriétaire

Ce à quoi vous êtes confronté, en clair

Si un freelance a configuré votre code et votre hébergement avec son propre e‑mail, vous ne contrôlez pas réellement les systèmes qui font tourner votre produit. Vous pouvez avoir les fichiers de l’appli sur votre ordinateur, mais les vrais points de contrôle sont les comptes : l’hébergeur de dépôts (comme GitHub), le registraire de domaine, le fournisseur d’hébergement ou cloud, l’e‑mail et tous les outils tiers.

Cela arrive pour des raisons normales. Un contractant va vite, utilise l’e‑mail déjà connecté sur sa machine et crée tout en tant que premier administrateur. Si personne ne pense à vous ajouter comme propriétaire, votre produit dépendra de la boîte mail d’une personne, de son gestionnaire de mots de passe et de son authentification à deux facteurs (2FA). Ce n’est souvent pas malveillant, juste la manière dont le travail a été réalisé.

Les risques sont immédiats et concrets. Sans le contrôle de ces comptes, vous pouvez être empêché de déployer des correctifs, de renouveler le domaine, de payer l’hébergement, de faire tourner des clés compromises, de supprimer d’anciens accès ou même d’obtenir de l’aide du support parce que vous ne pouvez pas prouver la propriété.

Quand des fondateurs disent qu’ils doivent récupérer GitHub et l’hébergement, ils veulent passer de « je peux voir l’appli » à « je peux la modifier, la livrer et la sécuriser sans demander à qui que ce soit ». C’est l’objectif.

Certaines parties sont généralement récupérables avec les bonnes étapes. Les dépôts peuvent souvent être transférés si le propriétaire coopère, ou exportés et ré‑importés s’il ne le fait pas. L’hébergement peut souvent être recréé dans un nouveau compte si vous avez le code, les réglages d’environnement et un moyen de pointer le domaine vers le nouveau serveur.

D’autres éléments prennent plus de temps. Les domaines sont le gros point d’achoppement. Si le compte du registraire et l’e‑mail du titulaire ne sont pas les vôtres, vous devrez peut‑être ouvrir des tickets support, fournir des preuves et patienter. L’e‑mail peut aussi bloquer : si votre « e‑mail admin » est en réalité la boîte du freelance ou sur son domaine, réinitialiser quoi que ce soit devient pénible.

Fixez les attentes tôt : c’est en partie de la négociation (obtenir un transfert propre), en partie des tickets support (prouver que vous êtes le propriétaire) et en partie du nettoyage (faire tourner les secrets, réparer les déploiements, supprimer les raccourcis risqués). Si le projet a été généré rapidement avec des outils d’IA puis retouché à la main, vous pouvez aussi découvrir du code fragile et des identifiants exposés au moment de la passation.

Premières 60 minutes : réduire le risque avant de toucher à la propriété

Votre objectif dans la première heure est d’éviter les surprises. Avant de demander des transferts ou d’ouvrir des tickets support, réduisez la probabilité que quelque chose soit modifié, supprimé ou facturé sans que vous le remarquiez.

Mettez en pause les déploiements et le travail en cours. Si le freelance a encore accès, même un « correctif rapide » peut écraser des réglages, faire tourner des secrets ou embrouiller la piste d’audit. Dites à votre équipe d’arrêter de merger et de publier jusqu’à ce que vous sachiez qui contrôle quoi.

Puis faites tourner ce à quoi vous avez déjà accès. C’est souvent le moyen le plus rapide de réduire les dégâts, même avant que la propriété soit réglée. Priorisez les comptes qui touchent l’argent, les données clients et l’authentification.

Faites les basiques d’abord :

• Changez les mots de passe admin de l’app et supprimez les utilisateurs admin inconnus.
• Faites tourner les mots de passe/utilisateurs de la base de données et révoquez les anciens lorsque c’est possible.
• Ré‑émettez les clés API (paiements, e‑mail, maps, analytics) et désactivez les anciennes clés.
• Mettez à jour les variables d’environnement accessibles.
• Activez la 2FA pour les comptes que vous contrôlez déjà.

Ensuite, capturez l’état actuel. Ce n’est pas du remplissage. Si quelque chose change plus tard, vous aurez besoin de preuves de ce qui existait et de qui payait. Faites des captures d’écran ou des exports depuis tous les tableaux de bord auxquels vous pouvez encore accéder, en particulier les pages de facturation, les permissions de dépôts, les enregistrements DNS, les réglages d’hébergement et la configuration CI/CD.

Commencez un journal d’incident immédiatement. Restez simple et cohérent, car les équipes support demanderont des dates et des preuves.

Notez :

• Dates et heures (avec fuseau)
• Qui vous avez contacté (freelance, agence, support)
• Où vous les avez contactés (e‑mail, chat)
• Ce que vous avez demandé (transfert, accès admin, changement de facturation)
• Numéros de ticket et résultats

Exemple : vous pouvez encore vous connecter à Stripe et au tableau de bord de l’appli, mais GitHub et l’hébergement sont sous l’e‑mail du freelance. Dans la première heure, vous suspendez les releases, faites tourner les secrets des webhooks Stripe et les mots de passe admin de l’appli, capturez les enregistrements DNS et consignez le message exact que vous avez envoyé pour demander un transfert. Cela vous place dans une position plus solide pour la suite.

Faire l’inventaire des comptes, propriétaires et preuves

Avant d’essayer de récupérer quoi que ce soit, notez ce qui existe et qui le contrôle aujourd’hui. Cela évite d’oublier le compte unique qui peut vous verrouiller plus tard (souvent le registraire de domaine, une boîte e‑mail partagée ou un système CI silencieux).

Listez chaque service qui touche votre appli. Pour beaucoup de startups, cela inclut un hébergeur de dépôts, un fournisseur d’hébergement, un registraire de domaine, un fournisseur d’e‑mail, une base de données et une poignée d’outils discrets comme analytics et suivi d’erreurs.

Utilisez un format simple pour chaque service :

• Ce qu’il contrôle (code, DNS, serveurs, e‑mail, paiements)
• E‑mail du compte et nom affiché
• Qui paie et quel nom figure sur les factures
• Méthode 2FA et qui la détient
• Options de récupération connues (codes de secours, e‑mail/téléphone de récupération)
• Statut : accès complet, accès partiel ou pas d’accès

L’accès partiel compte. Vous pouvez voir un dépôt sans pouvoir gérer les paramètres d’organisation, accéder aux logs d’un hébergeur sans gérer la facturation, ou éditer le DNS sans pouvoir transférer le domaine.

Ensuite, soulignez ce que vous contrôlez déjà. Ce sont vos points d’ancrage :

• Une boîte e‑mail d’entreprise à laquelle vous pouvez vous connecter
• Le moyen de paiement facturé
• Tout login admin dont vous disposez encore (même si ce n’est pas le propriétaire de plus haut niveau)
• L’accès au domaine (les domaines déterminent souvent tout le reste)

Enfin, rassemblez les preuves dont vous pourriez avoir besoin pour le support. Rangez‑les dans un dossier pour ne pas paniquer plus tard : factures, relevés bancaires ou de carte, contrat ou SOW, et l’historique des messages où la propriété et l’accès admin ont été discutés. Si vous avez les documents de création de l’entreprise, gardez‑les à portée aussi.

Comment demander au freelance un transfert propre

Considérez cela comme une passation, pas comme une rupture. Vous voulez un transfert propre avec le moins de drame et le moins de risque. Une demande calme et spécifique obtient généralement un oui plus rapide, surtout si le freelance n’a pas l’impression d’être accusé.

Facilitez la conformité. Au lieu de « donnez‑moi tout », envoyez une courte liste d’actions, dans l’ordre, avec un délai. Dites aussi que vous confirmerez une fois connecté et ayant vérifié les paramètres, pour qu’il sache que cela se terminera proprement.

Que demander (dans le bon ordre)

Demandez d’abord qu’il vous ajoute, puis le transfert une fois que vous avez vérifié. Cela maintient la stabilité pendant le changement d’accès.

1. Ajoutez votre e‑mail comme admin/propriétaire sur l’organisation ou le dépôt GitHub, le fournisseur d’hébergement et le compte du registraire de domaine.
2. Confirmez que vous pouvez vous connecter, voir la facturation et les permissions, et gérer la 2FA/options de récupération.
3. Transférez la propriété (dépôt/org, projet d’hébergement, domaine) vers l’e‑mail de votre entreprise.
4. Partagez les documents de passation : clone du dépôt, dump de la base, liste des variables d’environnement actuelles (ne collez pas de secrets en chat), étapes de déploiement et emplacement des logs/alertes.
5. Enlevez leur accès uniquement après que vous ayez confirmé que tout fonctionne.

Une phrase qui apaise : « Veuillez d’abord m’ajouter en tant qu’admin afin que je puisse vérifier que rien ne casse, ensuite nous ferons le transfert de propriété immédiatement après. »

Un message que vous pouvez copier

“Bonjour [Nom], nous avons besoin d’une passation propre des comptes du projet créés sous votre e‑mail. Pouvez‑vous ajouter [votre e‑mail] comme admin sur GitHub, l’hébergement et le compte du domaine aujourd’hui ? Une fois que j’ai vérifié l’accès, merci de transférer la propriété vers [e‑mail de l’entreprise]. Merci aussi de partager une sauvegarde (clone du dépôt, dernier export de la BDD) et des notes de déploiement basiques. Deadline : [date/heure]. Si vous êtes occupé·e, dites‑moi quand vous êtes disponible et je m’adapterai. Si nous ne pouvons pas finaliser d’ici là, j’ouvrirai des tickets auprès des plateformes et j’examinerai notre contrat pour que l’activité ne soit pas bloquée.”

Gardez tout par écrit. S’ils résistent, demandez quelle partie est difficile (temps, accès manquant, incertitude sur ce qu’il faut transférer) et ajustez le plan sans changer l’objectif.

Étapes pas à pas : transférer GitHub, l’hébergement, le domaine et la 2FA

L’objectif est simple : vous devenez le propriétaire partout, et toutes les clés cachées utilisées pour les déploiements et les connexions sont remplacées.

Faites les transferts dans un ordre qui évite de casser la production.

GitHub : déplacer la propriété sans casser les déploiements

Commencez par prendre le contrôle de l’organisation GitHub où le code doit vivre. Si vous n’avez pas encore d’organisation, créez‑en une sous un e‑mail géré par l’entreprise.

Étapes clés :

• Faites ajouter votre compte GitHub d’entreprise comme Owner (pas seulement collaborateur).
• Transférez chaque dépôt dans l’organisation.
• Faites tourner les éléments sensibles (surtout GitHub Actions et les secrets de dépôt). Supposez que tout ce que le freelance pouvait voir est compromis.
• Passez en revue les clés de déploiement et les OAuth/GitHub Apps liées au dépôt. Supprimez ce que vous ne reconnaissez pas et recréez des clés sous votre contrôle.
• Vérifiez les protections de branches pour qu’un ancien collaborateur ne puisse pas pousser directement sur main.

Avant de faire tourner les secrets, notez ce que les déploiements utilisent aujourd’hui (fournisseur CI, cible d’hébergement, noms d’environnement). Cela évite une panne évitable.

Hébergement, domaine et 2FA : reprendre les clés du royaume

La propriété du code aide, mais celui qui contrôle l’hébergement et le DNS peut toujours changer ce que voient les utilisateurs.

• Hébergement/cloud : faites‑vous ajouter comme admin/owner de plus haut niveau d’abord, puis déplacez la facturation vers un moyen de paiement de l’entreprise, puis retirez le freelance.
• Équipe/workspace : quand la plateforme le permet, placez les projets dans une équipe/org d’entreprise pour que l’accès ne dépende pas d’une seule personne.
• Domaine/registrar : transférez le domaine vers un compte que vous contrôlez et confirmez que vous pouvez éditer les enregistrements DNS. Confirmez aussi qui gère les réglages SSL/TLS et les renouvellements.
• E‑mail d’entreprise : remplacez les connexions plateformes qui utilisent l’e‑mail du freelance par une boîte contrôlée par l’entreprise.
• 2FA : réassociez la 2FA à vos appareils ou à une méthode gérée par l’entreprise. Régénérez les codes de secours et stockez‑les en lieu sûr.

Vérification après transferts : ouvrez une fenêtre incognito et vérifiez que votre compte admin peut (1) changer le DNS, (2) modifier la facturation et (3) déployer un changement test. Si l’un de ces éléments dépend encore du freelance, ce n’est pas fini.

Quand le freelance ne répond pas : travailler avec le support des plateformes

Si le freelance ne répond pas, le support est votre levier suivant. L’objectif est de prouver que vous êtes le propriétaire légitime et de faire déplacer l’actif vers un compte que vous contrôlez.

Rédigez une courte histoire cohérente que vous réutiliserez dans chaque ticket. Restez factuel : ce qu’est le projet, quels comptes sont bloqués, qui les a créés, quand vous avez payé et quel changement vous demandez.

Ce que le support demandera généralement

La plupart des plateformes demandent les mêmes catégories de preuves :

• Preuve de paiement (factures, reçus, relevés)
• Preuve d’entreprise (enregistrement de la société, preuve que vous la représentez)
• Preuve de contrôle du domaine (capacité à ajouter un enregistrement DNS, accès à l’e‑mail de facturation, historique de paiement chez le registraire)
• Indices de compte (noms d’utilisateur, noms d’orga, noms de dépôts, noms de domaine, dates approximatives de création)
• Vérifications de sécurité (adresse de facturation, 4 derniers chiffres de la carte, code PIN support si vous en avez un)

Quand le support pose des questions de suivi, répondez dans un seul message clair avec des pièces jointes étiquetées (par exemple : « Pièce A - facture »).

Ce qu’il faut demander (et éviter)

Demandez le plus petit changement qui vous donne le contrôle. Beaucoup d’équipes support n’« abandonneront » pas un compte entier sans preuve solide.

Demandes réalistes :

• Ajouter votre e‑mail comme owner/admin sur l’organisation, le dépôt ou le projet d’hébergement
• Changer l’e‑mail du compte pour une adresse contrôlée par l’entreprise
• Aider à migrer dépôts, projets ou abonnements vers un nouveau compte que vous créez
• Réinitialiser ou retirer la 2FA uniquement dans le cadre d’un processus de vérification de propriété

Évitez les demandes vagues comme « rendez‑moi le compte ». Mieux : « Veuillez ajouter mon e‑mail comme admin afin que je puisse transférer la propriété et faire tourner les identifiants. »

Les délais varient. Certains hébergeurs répondent en quelques heures. Les registraires et équipes d’identité peuvent prendre des jours et plusieurs échanges. Prévoyez 2–5 jours ouvrés, gardez un ticket par plateforme et mettez à jour votre journal d’incident.

Erreurs courantes qui compliquent la récupération

Le piège le plus fréquent est de penser « le site est en ligne, donc tout va bien ». Un prototype peut fonctionner et être pourtant dangereux. Les builds rapides incluent souvent des clés API exposées, des règles de login faibles ou des routes admin jamais verrouillées. Si vous attendez une compromission pour régler la propriété, le même problème devient un incident de sécurité.

Autre erreur : traiter ça comme un problème de mot de passe. Si le freelance a tout créé sous son e‑mail, obtenir « le bon mot de passe » ne vous donne pas le contrôle réel. Il vous faut un transfert de propriété : rôle admin, propriétaire de facturation, contrôle du titulaire du domaine et 2FA que vous gérez.

Les équipes trébuchent aussi sur les secrets. Des gens changent un mot de passe d’hébergement mais oublient les tokens présents à trois autres endroits. Avant tout mouvement, identifiez où existent les identifiants :

• Paramètres CI/CD (pipelines de build, clés de déploiement, tokens de service)
• Variables d’environnement d’hébergement (prod et preview)
• Le dépôt lui‑même (fichiers de config, commits anciens, exemples de .env)
• Code client (tout ce qui est livré au navigateur est effectivement public)
• Tableaux de bord tiers (paiements, e‑mail, analytics, suivi d’erreurs)

Les sauvegardes sont souvent sautées car tout le monde veut « juste transférer ». Puis les enregistrements DNS sont écrasés, une base est remplacée ou l’historique du dépôt est perdu lors d’un export précipité. Prenez un instant pour faire un snapshot propre : dépôt, base, buckets de stockage et réglages DNS actuels.

Enfin, ne faites pas de mouvements qui déclenchent des verrouillages sans plan. Révoquer un accès ou changer des e‑mails trop tôt peut provoquer des déploiements ratés ou une réaction défensive. Avancez dans un ordre contrôlé : confirmez que vous pouvez déployer et revenir en arrière, puis transférez la propriété, puis faites tourner les clés.

Checklist rapide : êtes‑vous en sécurité ?

« En sécurité » signifie que l’entreprise peut continuer à tourner si le freelance disparaît aujourd’hui.

Commencez par le point de défaillance unique le plus important : votre domaine. Si vous ne pouvez pas vous connecter au compte du registraire, vous ne contrôlez pas vraiment votre produit. Les changements DNS peuvent mettre votre site et vos e‑mails hors ligne rapidement.

Utilisez ceci comme contrôle pratique :

• Contrôle du domaine : vous pouvez vous connecter au registraire, éditer le DNS et le domaine ne peut pas être transféré sans votre approbation.
• Couverture admin : chaque plateforme critique a au moins deux admins de confiance (pas de logins partagés).
• Identité de l’entreprise : e‑mail de facturation, e‑mail de récupération et 2FA sont attachés à des boîtes et appareils contrôlés par l’entreprise.
• Sécurité des données : vous avez un clone récent du dépôt, un export de la BDD et une copie sécurisée des variables d’environnement nécessaires.
• Sécurité des déploiements : vous pouvez redéployer depuis votre propre compte et vous savez exactement où tourne l’appli live et qui y a accès.

Si un élément est « incertain », considérez‑le comme « non ».

Test simple : écrivez la connexion dont la perte mettrait l’entreprise à l’arrêt. Pour beaucoup d’équipes, c’est le registraire, l’e‑mail admin principal et le propriétaire du code. Corrigez‑les en priorité.

Scénario exemple : une fondatrice qui reprend le contrôle en 2 jours

Maya est une fondatrice solo. Un freelance a construit son MVP et l’a lancé vite : un dépôt GitHub (backend et frontend dans le même dépôt), une base gérée sur un hébergeur, et un domaine pointant vers un frontend simple. Ça marche, mais le freelance a tout créé sous son e‑mail et Maya n’a aucun accès admin.

Heure 0–2 (stabiliser) : Maya réduit d’abord le risque. Elle capture tout ce qu’elle trouve (e‑mails de facturation, factures, anciens identifiants, avis de renouvellement de domaine). Elle change les mots de passe des comptes qu’elle contrôle (e‑mail d’entreprise, portail de paiement) et suspend les paiements automatiques pour les services qu’elle ne peut pas atteindre.

Fin du Jour 1 (collecter les preuves et demander le transfert) : Maya rassemble les preuves que le projet lui appartient : contrat signé, reçus de paiement, site public montrant sa marque et les messages du freelance sur la mise en place. Elle envoie une demande claire : transférer le dépôt vers son organisation GitHub, la désigner comme propriétaire de facturation sur l’hébergement et déplacer le domaine vers son compte registraire.

Ce qu’elle peut faire immédiatement vs ce qui dépend des autres :

• Immédiatement : collecter les preuves, sécuriser l’e‑mail d’entreprise, lister les services, préparer les comptes propriétaires (org GitHub, hébergement, registraire).
• Dépend du contractant : initier les transferts, ajouter Maya comme owner/admin, fournir des codes de récupération 2FA ou retirer d’anciens appareils.
• Dépend du support : récupération forcée de domaine, litiges de dépôt, vérifications d’identité si le freelance disparaît.

Jour 2 (faire tourner les secrets et créer une voie propre) : Une fois que Maya a un quelconque accès, elle fait tourner tout ce qui pouvait être copié : mots de passe de la BDD, clés API, secrets d’auth, tokens de déploiement. Si elle ne peut pas obtenir d’accès, elle exécute un plan de secours : créer de nouveaux comptes, restaurer depuis des sauvegardes (ou exporter ce qu’elle peut depuis l’appli live) et redéployer sur une infrastructure qu’elle possède. Puis elle rédige une carte de propriété simple : qui possède GitHub, l’hébergement, le domaine, la BDD et la 2FA.

Étapes suivantes : verrouiller la propriété et éviter que ça se reproduise

Une fois que vous avez repris le contrôle, ne vous arrêtez pas à « ça marche ». Rendez difficile que votre produit soit bloqué derrière l’e‑mail d’une personne.

Créez une identité racine détenue par l’entreprise qui possède les éléments essentiels. Utilisez une boîte e‑mail contrôlée par l’entreprise (souvent une boîte admin partagée sur votre domaine) comme e‑mail de facturation et de récupération pour le registraire de domaine, l’organisation GitHub et les comptes d’hébergement. Gardez‑la ennuyeuse et stable. Elle ne doit appartenir ni à un freelance ni dépendre d’un employé personnel.

Mettez en place des règles simples qui collent à la réalité du travail en équipe :

• Gardez au moins deux owners/admins vérifiés sur chaque compte critique.
• Stockez les codes de récupération et les clés de licence dans un gestionnaire de mots de passe d’équipe.
• Exigez que les contractants utilisent leurs propres comptes en tant que membres, jamais en tant que propriétaires.
• Utilisez une checklist de passation courte en fin de contrat (ce qu’ils ont construit, où ça tourne, comment déployer, où sont les secrets).
• Faites un exercice trimestriel d’accès : confirmez que vous pouvez vous connecter et faire tourner un token sans l’auteur original.

Si votre appli a été construite rapidement avec des outils d’IA ou assemblée à la va‑vite, prévoyez du temps pour nettoyer avant de la traiter comme de la production. Les corrections de propriété ne sont que la moitié de l’histoire. Le code bâclé et les déploiements pressés cachent souvent des problèmes comme des secrets codés en dur, des flux d’authentification cassés ou des requêtes SQL non sécurisées.

Approche pratique : figez les changements pendant une journée, migrez les secrets vers de véritables variables d’environnement ou un coffre à secrets, et écrivez une source de vérité pour le déploiement (où c’est hébergé, comment déployer, à quoi ressemble un état sain). Même une page de notes sauve des semaines plus tard.

Si vous voulez de l’aide extérieure, FixMyMess (fixmymess.ai) est spécialisé dans la transformation de prototypes générés par l’IA en applis prêtes pour la production. Un audit rapide peut aussi révéler les mines de la passation : secrets exposés, authentification cassée et configurations de déploiement ne fonctionnant que depuis la machine du constructeur.

Considérez la propriété des comptes comme partie intégrante du produit, pas comme de l’administratif. Suivez les accès, propriétaires et étapes de récupération comme vous suivez les bugs et les fonctionnalités, pour qu’aucune personne ne puisse bloquer l’activité à l’avenir.