[{"data":1,"prerenderedAt":225},["ShallowReactive",2],{"seo-verification":3,"blog-migrer-gitlab-com-vers-self-managed-vps-fr":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-migrer-gitlab-com-vers-self-managed-vps-fr",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":27,"featuredImage":29,"bgImage":30,"posterImage":31,"relatedSolution":29,"intro":32,"sections":33,"ctaTitle":162,"ctaBody":163,"ctaButton":164,"ctaUrl":165,"relatedPosts":166},498,"migrer-gitlab-com-vers-self-managed-vps",{"fr":10,"en":12,"ar":13,"es":14},"migrate-gitlab-com-to-self-managed-gitlab-vps","ترحيل-gitlab-com-إلى-gitlab-ذاتي-الاستضافة-على-vps","migrar-gitlab-com-a-gitlab-autoalojado-vps","Migrer GitLab.com vers une instance self-managed sur VPS","Migrez groupes et projets de GitLab.com vers votre instance GitLab sur VPS : export, direct transfer, membres, variables CI\u002FCD et registre à reconstituer à la main.",11,0,false,"2026-10-23T00:00:00+00:00","2026-10-23T23:43:01+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},3,"Déploiement","deploiement","bg-success\u002F10 text-success",[28],{"id":23,"name":24,"slug":25,"color":26,"icon":25},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fmigrer-gitlab-com-vers-self-managed-vps-poster.svg","Votre agence garde le code de plusieurs clients sur un compte GitLab.com, et la facture comme la rétention ne sont pas réglées par vous. Reprendre la main passe par une instance GitLab sur votre propre VPS, mais l'export de projet n'emporte pas tout : variables CI\u002FCD, images du registre, webhooks et jetons restent derrière. Ce guide planifie la migration, déroule le direct transfer, règle le rattachement des membres et reconstitue ce qui manque, avec un ordre de bascule réversible. L'ancien projet reste en lecture seule jusqu'à validation.",[34,38,47,50,82,85,119,122,125,140,144,147,156,159],{"type":35,"title":36,"body":37},"h2","Pourquoi sortir de GitLab.com pour une instance self-managed","Quand les tarifs d'un outil SaaS bougent, comme la récente hausse d'Atlassian Cloud détaillée dans \u003Ca href=\"\u002Fblog\u002Fatlassian-double-choc-tarif-octobre-decembre-2026\">notre article sur le double choc tarifaire\u003C\u002Fa>, les équipes réévaluent tout leur outillage de développement. Pour une agence, la question est concrète : le code de dix clients vit sur un compte unique, chez un tiers, avec une rétention et des accès que l'on ne règle pas soi-même.\n\nUne instance auto-gérée déplace ces décisions chez vous : où sont stockés les dépôts, combien de temps on garde les artefacts, qui peut se connecter, et ce que cela coûte chaque mois. Le prix de cette liberté est un travail de migration que GitLab ne fait pas entièrement à votre place.\n\nCe guide ne reprend ni le choix de la forge, traité dans \u003Ca href=\"\u002Fblog\u002Fcomparatif-forge-git-self-hosted-2026\">le comparatif des forges\u003C\u002Fa>, ni l'installation, décrite dans \u003Ca href=\"\u002Fblog\u002Finstaller-gitlab-ce-vps\">le guide d'installation de GitLab CE\u003C\u002Fa>. Il part d'une instance GitLab déjà en ligne et s'occupe uniquement du passage de GitLab.com vers elle.",{"type":39,"title":40,"items":41},"ul","Ce que vous gagnez en reprenant l'hébergement",[42,43,44,45,46],"**Des accès sous votre contrôle** — comptes, groupes et rôles se gèrent sur votre instance, pas sur un compte SaaS partagé entre clients.","**Une rétention que vous fixez** — durée de conservation des artefacts et des journaux, volume du registre, tout se règle dans l'administration.","**Une facture qui suit votre VPS** — le coût dépend de la machine que vous dimensionnez, pas d'un nombre de sièges.","**Un nom de domaine à vous** — le dépôt répond sur `git.votre-domaine.com`, avec votre certificat et votre pare-feu.","**Une migration par étapes** — l'ancien projet reste en place, en lecture seule, tant que le nouveau n'est pas validé.",{"type":35,"title":48,"body":49},"Ce que la migration n'emporte pas, à inventorier avant tout","La documentation officielle de l'export de projet liste ce qui n'est pas exporté : l'historique des pipelines enfants, les déclencheurs de pipeline, les traces et artefacts de jobs CI\u002FCD, les images du registre de conteneurs et de paquets, les variables CI\u002FCD, les webhooks, les jetons chiffrés, le nombre d'approbations requises, les clés de déploiement autorisées sur les branches protégées, les fichiers sécurisés et les variables des planifications de pipeline. Les clés de déploiement ne sont pas non plus importées : il faut les réactiver dans le projet importé.\n\nLe direct transfer a sa propre liste d'exclusions, qui recoupe la première : variables CI\u002FCD, webhooks, images du registre, registre de paquets, journaux et artefacts de jobs. Au niveau du groupe, les variables CI\u002FCD, les jetons de déploiement et les règles de push ne suivent pas non plus.\n\nÉcrivez cet inventaire dans un tableau avant de commencer : une ligne par projet, une colonne par élément manquant, une colonne pour la personne qui le recrée. C'est ce document, plus que l'export lui-même, qui vous protège le jour où l'ancien accès ferme.",{"type":51,"title":52,"headers":53,"rows":57},"comparison","Export de projet ou direct transfer : ce que chaque méthode couvre",[54,55,56],"Élément","Export de projet (fichier)","Direct transfer",[58,62,66,68,72,74,78],[59,60,61],"Granularité","Un projet à la fois, via un fichier téléchargé","Groupes entiers, avec ou sans leurs projets, depuis l'interface",[63,64,65],"Variables CI\u002FCD","Non exportées","Non migrées",[67,64,65],"Images du registre de conteneurs",[69,70,71],"Webhooks","Non exportés","Non migrés",[73,70,71],"Journaux et artefacts de jobs",[75,76,77],"Membres","Rattachés si l'e-mail public source correspond à l'e-mail principal de destination","Rattachés si l'e-mail public source correspond à un e-mail confirmé de destination",[79,80,81],"Ce qu'il faut côté instance","Un administrateur réalise l'import","Fonction activée par un administrateur, jeton avec le scope `api` côté source",{"type":35,"title":83,"body":84},"Prérequis : versions, droits et ressources de votre instance","Première règle, la version. L'import d'un fichier accepte des exports issus d'une version jusqu'à deux versions mineures en arrière de la destination, et la documentation demande que la destination soit au moins à la version de la source. Pour le direct transfer, la documentation recommande GitLab 16.8 ou plus récent des deux côtés, et demande qu'une source ne retarde pas de plus de deux versions mineures sur la destination. GitLab.com avance en continu : visez la dernière version stable disponible pour votre instance, mettez-la à jour avant de migrer, pas après, et relisez l'écart toléré dans la documentation le jour J.\n\nCôté droits, il vous faut le rôle Owner sur le groupe source, un administrateur sur l'instance cible, et un jeton d'accès personnel avec le scope `api` créé sur GitLab.com. Les deux instances doivent se joindre en HTTPS, avec de l'espace libre dans `\u002Ftmp`.\n\nCôté ressources, notre recommandation éditoriale : 4 vCPU et 8 Go de RAM pour une instance qui héberge aussi le registre, un disque NVMe dimensionné sur la taille cumulée des dépôts et des images, et des runners sur un VPS à part dès que les builds sont lourds. L'installation elle-même est décrite dans \u003Ca href=\"\u002Fblog\u002Finstaller-gitlab-ce-vps\">le guide GitLab CE sur VPS\u003C\u002Fa>.",{"type":86,"title":87,"steps":88},"steps","Planifier et exécuter la migration, de l'inventaire à la bascule",[89,92,95,98,101,104,107,110,113,116],{"title":90,"body":91},"Inventorier groupes, projets et dépendances","Listez chaque groupe, chaque projet, ses variables, ses webhooks, ses runners et ses intégrations. Notez qui en est propriétaire côté client.",{"title":93,"body":94},"Mettre l'instance cible à jour","Vérifiez la version dans l'administration, et visez la dernière version stable disponible, au moins égale à celle de GitLab.com, avant tout import.",{"title":96,"body":97},"Créer les utilisateurs sur la cible","Les membres ne se créent pas pendant la migration. Créez les comptes avant, avec l'e-mail principal que chaque personne utilise sur GitLab.com.",{"title":99,"body":100},"Prévoir un groupe par client","Créez sur la cible un groupe ou sous-groupe par client, avec les droits minimaux, avant d'importer.",{"title":102,"body":103},"Faire publier les e-mails côté source","Chaque membre renseigne un e-mail public dans son profil GitLab.com, au moins jusqu'à la fin de l'import.",{"title":105,"body":106},"Activer le direct transfer sur l'instance cible","Un administrateur active la migration de groupes par direct transfer dans les paramètres de l'application. Elle est désactivée par défaut sur une instance auto-gérée.",{"title":108,"body":109},"Lancer l'import du groupe","Sur la cible, choisissez **Create new** puis **New group** puis **Import group**, saisissez `https:\u002F\u002Fgitlab.com` et votre jeton, puis **Connect instance**. Sélectionnez les groupes avec **Import with projects**.",{"title":111,"body":112},"Exporter à la main les projets isolés","Pour un projet hors groupe, ouvrez **Settings** puis **General** puis **Advanced** puis **Export project**, téléchargez le fichier et importez-le sur la cible.",{"title":114,"body":115},"Suivre l'import et relire les erreurs","La colonne **Status** indique l'avancement. Sur un import en échec ou partiel, **Show errors** détaille la cause. Comptez plusieurs heures pour un grand nombre de projets.",{"title":117,"body":118},"Brancher la suite sur le registre et la CI","Reconstituez variables et images comme décrit plus bas, puis relancez un pipeline complet sur la cible avant de toucher à l'ancien projet.",{"type":35,"title":120,"body":121},"Membres et assignees : la règle de rattachement","Sur une instance auto-gérée, la règle publiée est la suivante : les utilisateurs doivent déjà exister sur la destination, et l'e-mail public du compte source doit correspondre à l'e-mail principal du compte de destination. Si les conditions sont réunies, la personne est ajoutée comme membre direct. Sinon, l'association passe à l'utilisateur qui réalise l'import : vos auteurs de commentaires et vos assignees se retrouvent tous à votre nom.\n\nAvant l'import, vérifiez sur chaque profil GitLab.com le champ **Public email**. Pour un export de projet, vous pouvez aussi ajouter des e-mails publics en éditant le fichier `project_members.ndjson` de l'archive. Le propriétaire du groupe de premier niveau doit lancer l'export pour que les membres directs et hérités soient inclus, et un administrateur doit réaliser l'import.\n\nAvec le direct transfer, les adhésions importées sont d'abord associées à des utilisateurs substituts, avant réaffectation. Une case **Import user memberships** permet aussi de ne pas importer les adhésions. Dans ce cas, c'est l'e-mail public source face à un e-mail confirmé de destination qui décide du rattachement, pas l'e-mail principal comme pour l'import de fichier.\n\nPour une agence, structurez la cible avant d'importer : un groupe de premier niveau par client, ou un sous-groupe par client sous un groupe d'agence. Donnez à chaque client le rôle minimal sur son seul groupe (Reporter ou Developer plutôt qu'Owner), gardez le rôle Owner pour l'équipe interne, et vous pourrez plus tard sortir un client en lui transférant son groupe ou en exportant ses projets, sans toucher aux autres.",{"type":35,"title":123,"body":124},"Variables CI\u002FCD et registre de conteneurs : reconstituer à la main","Les variables ne voyagent pas, parce que GitLab les considère comme sensibles. Listez-les côté source avec l'API : `curl --header \"PRIVATE-TOKEN: \u003Cjeton>\" \"https:\u002F\u002Fgitlab.com\u002Fapi\u002Fv4\u002Fprojects\u002F\u003Cid>\u002Fvariables\"`. La liste donne clé, attributs `masked` et `protected` et, en général, la valeur ; mais toutes les valeurs ne sont pas forcément relisibles, selon la version et la façon dont la variable a été créée.\n\nRecréez-les ensuite sur la cible avec `curl --request POST --header \"PRIVATE-TOKEN: \u003Cjeton>\" --form \"key=NOM\" --form \"value=valeur\" \"https:\u002F\u002Fgit.votre-domaine.com\u002Fapi\u002Fv4\u002Fprojects\u002F\u003Cid>\u002Fvariables\"`. La clé accepte 255 caractères parmi `A-Z`, `a-z`, `0-9` et `_`. Quand la valeur manque ou reste masquée, recréez le secret chez son fournisseur et notez-le dans le coffre de l'agence.\n\nLes variables de groupe se recréent depuis les réglages CI\u002FCD du groupe. Les runners, eux, se réenregistrent sur la nouvelle instance : leurs jetons ne suivent pas.",{"type":86,"title":126,"steps":127},"Transférer les images du registre vers la nouvelle URL",[128,131,134,137],{"title":129,"body":130},"Activer le registre sur l'instance cible","Dans `\u002Fetc\u002Fgitlab\u002Fgitlab.rb`, définissez `registry_external_url` en HTTPS, par exemple `https:\u002F\u002Fregistry.votre-domaine.com`, puis lancez `sudo gitlab-ctl reconfigure`. Le registre exige un certificat TLS.",{"title":132,"body":133},"Créer un jeton pour chaque côté","Un jeton avec `read_registry` suffit pour tirer les images, et `write_registry` en plus pour les pousser.",{"title":135,"body":136},"Tirer chaque image depuis l'ancienne URL","Connectez-vous avec `docker login registry.gitlab.com`, puis `docker pull registry.gitlab.com\u002Fgroupe\u002Fprojet\u002Fimage:tag`.",{"title":138,"body":139},"Retaguer puis pousser vers la cible","Exécutez `docker tag registry.gitlab.com\u002Fgroupe\u002Fprojet\u002Fimage:tag registry.votre-domaine.com\u002Fgroupe\u002Fprojet\u002Fimage:tag`, puis `docker login registry.votre-domaine.com` et `docker push registry.votre-domaine.com\u002Fgroupe\u002Fprojet\u002Fimage:tag`. Les chemins de dépôt du registre s'écrivent en minuscules.",{"type":141,"title":142,"body":143},"tip","Gardez la marche arrière ouverte","Ne supprimez rien à la source. Passez l'ancien projet en archivé ou retirez les droits d'écriture, gardez-le lisible, puis relancez un pipeline et un `git clone` complet depuis la cible. Tant que la validation n'est pas signée par le client, la bascule reste réversible : il suffit de réouvrir l'ancien projet.",{"type":35,"title":145,"body":146},"Dépannage : les erreurs d'authentification et d'import","Au `docker login` ou au `docker push`, le message `access forbidden` signifie, selon la documentation, que l'en-tête `Authorization` a été retiré avant d'atteindre GitLab, souvent par un proxy placé devant l'instance. Vérifiez la configuration du reverse proxy.\n\nUne erreur `UNAUTHORIZED` (401) indique des identifiants faux ou expirés, des scopes manquants, ou un mot de passe utilisé avec la double authentification activée : utilisez alors un jeton. Un `DENIED` (403) veut dire que les identifiants sont valides mais sans droit sur le registre.\n\nSur une grosse image, `unauthorized: authentication required` signale un jeton expiré avant la fin du push. Un administrateur peut allonger sa durée.\n\nCôté import, un titre de jalon déjà existant reçoit un suffixe unique du type `18.0 (imported-…)` : renommez le jalon avant la migration pour l'éviter.",{"type":39,"title":148,"items":149},"Contrôles avant de couper l'ancien accès",[150,151,152,153,154,155],"**Dépôts identiques** — comparez les branches et les tags, puis faites un clone complet depuis la cible.","**Pipeline complet vert** — un pipeline sur la branche principale avec les variables recréées et les runners réenregistrés.","**Images présentes** — chaque tag utilisé par un déploiement existe dans le nouveau registre.","**Membres et rôles relus** — aucun auteur ni assignee n'a basculé sur le compte qui a lancé l'import.","**Webhooks et clés de déploiement recréés** — intégrations de chat, de déploiement et de supervision comprises.","**Validation écrite par le client** — l'ancien projet ne se ferme qu'après cet accord.",{"type":35,"title":157,"body":158},"La documentation officielle","Les règles de ce guide viennent de la documentation GitLab : \u003Ca href=\"https:\u002F\u002Fdocs.gitlab.com\u002Fee\u002Fuser\u002Fproject\u002Fsettings\u002Fimport_export.html\">export et import de projet\u003C\u002Fa>, \u003Ca href=\"https:\u002F\u002Fdocs.gitlab.com\u002Fee\u002Fuser\u002Fgroup\u002Fimport\u002Fdirect_transfer_migrations.html\">migration de groupes par direct transfer\u003C\u002Fa>, \u003Ca href=\"https:\u002F\u002Fdocs.gitlab.com\u002Fee\u002Fuser\u002Fgroup\u002Fimport\u002Fmigrated_items.html\">éléments migrés\u003C\u002Fa>, \u003Ca href=\"https:\u002F\u002Fdocs.gitlab.com\u002Fee\u002Fapi\u002Fproject_level_variables.html\">API des variables de projet\u003C\u002Fa>, \u003Ca href=\"https:\u002F\u002Fdocs.gitlab.com\u002Fee\u002Fuser\u002Fpackages\u002Fcontainer_registry\u002Fauthenticate_with_container_registry.html\">authentification au registre\u003C\u002Fa> et \u003Ca href=\"https:\u002F\u002Fdocs.gitlab.com\u002Fee\u002Fadministration\u002Fpackages\u002Fcontainer_registry.html\">registre sur une instance auto-gérée\u003C\u002Fa>. Relisez-les à la date de votre migration : les listes d'éléments migrés évoluent.",{"type":35,"title":160,"body":161},"Et ensuite : consolider autour de votre instance","Une fois les projets validés, l'instance devient le point central du portefeuille de l'agence. Pour un registre plus lourd, \u003Ca href=\"\u002Fblog\u002Fself-host-harbor-registry-vps\">Harbor sur un VPS\u003C\u002Fa> peut prendre le relais. Si votre migration vient d'un autre outil de tickets, \u003Ca href=\"\u002Fblog\u002Fmigrer-jira-openproject-plane-vps-2026\">le guide Jira vers OpenProject ou Plane\u003C\u002Fa> suit la même logique d'inventaire. Et si vous hésitez encore sur la forge, \u003Ca href=\"\u002Fblog\u002Fmigrer-gitlab-vers-gitea-vps-2026\">le passage de GitLab vers Gitea\u003C\u002Fa> reste une option plus légère.","Reprenez la main sur le code de vos clients","Une agence qui héberge ses dépôts sur sa propre instance maîtrise ses accès, sa rétention et sa facture. Sur ServOrbit, l'instance tourne sur un VPS root à IPv4 dédiée, et le nom de domaine du dépôt se gère au même endroit que vos hébergements et votre revendeur.","Découvrir les solutions agences","\u002Fsolutions\u002Fagences",[167,183,206],{"id":168,"slug":169,"slugs":170,"title":174,"excerpt":175,"readTime":176,"views":23,"isPinned":19,"publishedAt":177,"updatedAt":178,"category":179,"categories":180,"featuredImage":29,"bgImage":30,"posterImage":182,"relatedSolution":29},235,"installer-gitlab-ce-vps",{"fr":169,"en":171,"ar":172,"es":173},"install-gitlab-ce-on-a-vps-complete-guide","تثبيت-gitlab-ce-على-vps-دليل-شامل","instalar-gitlab-ce-en-un-vps-guia-completa","Installer GitLab CE sur VPS : guide complet","Déployez GitLab CE sur VPS avec Docker Compose. Inclut le patch CVE-2026-90970 (CVSS 9.9) : AI Gateway RCE, versions vulnérables et commandes de mise à jour.",18,"2026-08-07T00:00:00+00:00","2026-10-20T23:18:07+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},[181],{"id":23,"name":24,"slug":25,"color":26,"icon":25},"\u002Fblog\u002Fcovers\u002Finstaller-gitlab-ce-vps-poster.svg",{"id":184,"slug":185,"slugs":186,"title":190,"excerpt":191,"readTime":192,"views":18,"isPinned":19,"publishedAt":193,"updatedAt":194,"category":195,"categories":201,"featuredImage":29,"bgImage":30,"posterImage":203,"relatedSolution":204},352,"migrer-gitlab-vers-gitea-vps-2026",{"fr":185,"en":187,"ar":188,"es":189},"migrate-gitlab-to-gitea-vps-2026","الانتقال-من-gitlab-إلى-gitea-على-vps-في-2026","migrar-gitlab-a-gitea-en-un-vps-en-2026","Migrer de GitLab vers Gitea sur VPS en 2026","GitLab.com impose la lecture seule aux namespaces de plus de 5 membres depuis le 15 août 2026. Voici comment migrer vers Gitea auto-hébergé sans perdre l'historique.",10,"2026-09-16T00:00:00+00:00","2026-10-20T23:18:06+00:00",{"id":196,"name":197,"slug":198,"color":199,"icon":200},4,"Développement","developpement","bg-warning\u002F10 text-warning","dev",[202],{"id":196,"name":197,"slug":198,"color":199,"icon":200},"\u002Fblog\u002Fcovers\u002Fmigrer-gitlab-vers-gitea-vps-2026-poster.svg",{"categorySlug":198,"appSlug":205},"gitea",{"id":207,"slug":208,"slugs":209,"title":213,"excerpt":214,"readTime":192,"views":18,"isPinned":19,"publishedAt":215,"updatedAt":216,"category":217,"categories":222,"featuredImage":29,"bgImage":30,"posterImage":224,"relatedSolution":29},398,"atlassian-double-choc-tarif-octobre-decembre-2026",{"fr":208,"en":210,"ar":211,"es":212},"atlassian-pricing-shock-oct-2026-hike-and-usage-billing","atlassian-رفع-الاسعار-اكتوبر-2026-فوترة-الاستخدام","atlassian-subida-oct-2026-facturacion-por-uso","Atlassian : hausse oct. 2026 et facturation à l'usage déc.","Atlassian hausse ses prix Cloud de 7 à 10 % le 13 octobre 2026, puis facture les automation steps et Rovo AI credits le 3 décembre. Évaluez le VPS self-hosted.","2026-09-30T00:00:00+00:00","2026-10-20T23:18:05+00:00",{"id":218,"name":219,"slug":220,"color":221,"icon":220},5,"Comparatif","comparatif","bg-info\u002F10 text-info",[223],{"id":218,"name":219,"slug":220,"color":221,"icon":220},"\u002Fblog\u002Fcovers\u002Fatlassian-double-choc-tarif-octobre-decembre-2026-poster.svg",1792799325702]