# Connecter GitHub, GitLab ou Bitbucket pour déployer

> Connectez GitHub, GitLab (même auto-hébergé) ou Bitbucket pour choisir vos dépôts, ajouter des deploy keys en lecture seule et déployer à chaque push.

Les connexions Git relient vos comptes Git à votre organisation, pour que les sites puissent être déployés depuis vos dépôts. Vimonto Deploy prend en charge **GitHub**, **GitLab** (gitlab.com), **GitLab (auto-hébergé)** et **Bitbucket**. Avec une connexion, vous choisissez un dépôt et une branche dans une liste quand vous [créez un site](https://ops.vimonto.com/docs/fr/sites/create-a-site), et Vimonto Deploy configure le dépôt pour vous : une deploy key en lecture seule pour que le serveur puisse le cloner, et un webhook de push pour que chaque push puisse lancer un [déploiement](https://ops.vimonto.com/docs/fr/sites/deployments).

Vous connectez GitHub, GitLab et Bitbucket avec OAuth (un clic, en vous connectant chez l'hébergeur Git) ; un GitLab auto-hébergé avec un personal access token. Vous pouvez connecter plusieurs comptes, même sur le même service. Ils se trouvent dans la section **Git** de **Paramètres** → [Intégrations](https://ops.vimonto.com/docs/fr/connections/integrations).

![La section Git avec les comptes GitHub, GitLab et Bitbucket connectés](https://ops.vimonto.com/docs-media/fr/source-control.webp?v=161e760d "Paramètres → Intégrations → Git")

## Qui peut connecter un compte Git ?

Chaque membre peut voir les comptes connectés. Connecter, tester, renommer, reconnecter et déconnecter nécessite le rôle **Propriétaire** ou **Administrateur**. Une fois un compte connecté, chaque membre autorisé à gérer les sites peut l'utiliser pour ses sites. Les connexions, renommages et déconnexions sont enregistrés dans le [journal d’audit](https://ops.vimonto.com/docs/fr/organization/audit-log), sans les tokens.

## Connecter GitHub, GitLab ou Bitbucket

1. Ouvrez **Paramètres** → **Intégrations**.
2. Sous **Ajouter une intégration**, choisissez **Connecter** sur la carte **GitHub**, **GitLab** ou **Bitbucket**.
3. Connectez-vous chez l'hébergeur Git et autorisez l'accès.
4. Vous revenez sur **Intégrations** avec un message confirmant que le compte est connecté. La connexion porte le nom du service et de votre nom d'utilisateur chez lui, par exemple `GitHub (octocat)`.

Si vous connectez une seconde fois le même compte, Vimonto Deploy met à jour la connexion existante au lieu d'en ajouter un doublon.

> [!NOTE]
> Un hébergeur Git affiche **Bientôt disponible** tant qu'un administrateur de la plateforme n'a pas enregistré son application OAuth (une seule fois, pour toute la plateforme, dans **Admin** → **Intégrations**). Les administrateurs voient à la place **Configurer** sur la carte.

### Quel accès Vimonto Deploy demande-t-il ?

| Service | Accès demandé | Pourquoi |
| --- | --- | --- |
| GitHub | `repo`, `admin:repo_hook`, `read:user`, `read:org` | Lire vos dépôts (y compris les dépôts privés et ceux de vos organisations GitHub), ajouter des deploy keys et des webhooks de push |
| GitLab | `api` | Lire vos projets, ajouter des deploy keys et des webhooks de push |
| Bitbucket | Account: Read, Repositories: Admin, Webhooks: Read and write | Lire vos dépôts, ajouter des deploy keys et des webhooks de push |

Avec OAuth, Vimonto Deploy a accès à tous les dépôts que le compte peut voir. Vous voulez restreindre cet accès ? Utilisez plutôt une **URL Git personnalisée** avec la deploy key propre au site, et ajoutez vous-même cette clé à l'unique dépôt concerné.

## Connecter un GitLab auto-hébergé

1. Dans votre GitLab, ouvrez **Preferences** → **Access tokens** → **Add new token**.
2. Choisissez le scope `api` et une date d'expiration conforme à votre politique.
3. Dans Vimonto Deploy, choisissez **Connecter** sur la carte **GitLab (auto-hébergé)** sous **Ajouter une intégration**.
4. Saisissez l'**Adresse de votre GitLab** (par exemple `https://gitlab.company.com`) et le **Personal access token**.
5. Choisissez **Vérifier et connecter**.

Vimonto Deploy vérifie immédiatement le token en demandant à GitLab à qui il appartient. L'adresse doit utiliser HTTPS. Votre GitLab doit être joignable depuis Vimonto Deploy (pour l'API) et depuis vos serveurs (pour cloner).

> [!WARNING]
> Un personal access token cesse de fonctionner à sa date d'expiration. Les sites déjà liés continuent de se déployer, car le serveur clone avec la deploy key du site et les push arrivent par le webhook. Mais Vimonto Deploy ne peut alors plus lister vos projets, ni ajouter ou retirer des deploy keys et des webhooks. Avant ou après la date d'expiration, choisissez **Mettre à jour le jeton** dans le menu (⋯) de la connexion, collez un nouveau token du même compte GitLab, puis choisissez **Vérifier et enregistrer**. La connexion et les sites qui l'utilisent restent tels quels.

## Choisir un dépôt pour un site

Quand vous [créez un site](https://ops.vimonto.com/docs/fr/sites/create-a-site), choisissez le compte connecté sous **Code source**. Affinez la liste avec **Organisation** si vous le souhaitez, puis choisissez le **Dépôt** et sa branche. La liste commence par les 100 dépôts sur lesquels le compte a été actif le plus récemment. Tapez dans le champ de recherche pour chercher parmi tous les dépôts auxquels le compte a accès chez l'hébergeur Git ; ce qui est trouvé est ajouté à la liste. Vous pouvez aussi utiliser n'importe quel dépôt via une **URL Git personnalisée**. Vous changez plus tard le dépôt d'un site sur sa page **Déploiements**.

## Que se passe-t-il quand un site utilise une connexion ?

Quand vous créez un site avec un dépôt d'un compte connecté, ou que vous changez plus tard le dépôt d'un site, Vimonto Deploy lance une tâche qui lie le dépôt :

1. **Deploy key.** Par défaut, chaque site reçoit sa propre paire de clés SSH (l'option **Clé de déploiement dédiée pour …** à la création d'un site). La clé publique est ajoutée au dépôt chez l'hébergeur Git comme deploy key en **lecture seule**, nommée d'après le domaine et le serveur du site. La clé privée est placée sur le serveur : le serveur peut cloner et faire un pull, mais jamais un push.
2. **Webhook de push.** Pour un dépôt d'un compte connecté, **Déployer à chaque push** (déploiement rapide) est activé : Vimonto Deploy ajoute donc au dépôt un webhook qui envoie chaque push à l'URL de déploiement du site. Les push sur la branche du site lancent alors un déploiement. Désactiver le déploiement rapide sur la page **Déploiements** du site supprime à nouveau le webhook. Si l'hébergeur Git refuse le webhook, le déploiement rapide est désactivé et la tâche indique pourquoi ; le site se déploie toujours quand vous lancez un déploiement.
3. **Premier déploiement.** Pour un nouveau site, le premier déploiement démarre dès que le dépôt est lié.
4. **Nettoyage.** Quand vous passez un site sur un autre dépôt ou une autre connexion, ou que vous supprimez le site, l'ancienne deploy key et l'ancien webhook sont retirés de l'hébergeur Git. Si cela échoue, par exemple parce que l'accès de l'ancienne connexion a expiré, la tâche l'indique, et vous les retirez vous-même chez l'hébergeur Git. Lors d'un changement, le site reçoit alors une nouvelle deploy key, pour que le nouveau dépôt ne refuse pas l'ancienne.

Sans deploy key propre, un site clone avec la clé du serveur. Vous trouvez cette clé sous **Clé publique du serveur** dans la vue d'ensemble du serveur ; ajoutez-la vous-même à votre hébergeur Git.

> [!NOTE]
> Sur GitHub, une deploy key ne peut être utilisée que par un seul dépôt. Si GitHub refuse la clé du site parce qu'elle se trouve encore sur un autre dépôt, Vimonto Deploy donne au site une nouvelle deploy key et ajoute celle-ci à la place. Retirez vous-même l'ancienne clé de l'autre dépôt.

## Renouvellement des tokens

Certains hébergeurs Git délivrent des tokens d'accès qui expirent au bout de quelques heures (toujours chez GitLab et Bitbucket, selon l'application chez GitHub). Vimonto Deploy enregistre le refresh token et obtient de lui-même un nouveau token d'accès, juste avant qu'une requête en ait besoin. Vous n'avez pas besoin de vous reconnecter pour cela.

Si le renouvellement échoue, parce que l'accès a été révoqué chez l'hébergeur Git ou que le compte a été supprimé, les requêtes échouent avec un message comme « La connexion à GitHub a expiré. Reconnectez-vous. » Choisissez **Reconnecter** dans le menu de la connexion pour vous connecter à nouveau ; vos sites continuent d'utiliser la même connexion.

## Tester, renommer et reconnecter une connexion

Chaque connexion affiche **Fonctionne** quand sa dernière vérification a réussi, sinon **Reconnecter**. Dans le menu (⋯) à côté d'une connexion, vous pouvez :

- **Tester la connexion** : demande à l'hébergeur Git à quel compte appartient le token et affiche « Connecté en tant que … ».
- **Reconnecter** : se reconnecte avec OAuth et renouvelle les tokens (GitHub, GitLab et Bitbucket).
- **Mettre à jour le jeton** : remplace le personal access token d'une connexion **GitLab (auto-hébergé)** (uniquement celles-ci). Le nouveau token doit appartenir au même compte GitLab.
- **Renommer** : change le nom affiché dans Vimonto Deploy.
- **Déconnecter** : supprime la connexion.

## Déconnecter un compte Git

Choisissez **Déconnecter** dans le menu et confirmez. La déconnexion n'empêche aucun site de se déployer. Ce qui s'arrête, c'est tout ce qui passe par le compte : vous ne pouvez plus y choisir de dépôts, et Vimonto Deploy ne peut plus ajouter ni retirer des deploy keys et des webhooks sur ses dépôts. Les sites liés par ce compte gardent leur adresse de dépôt, leur deploy key et leur webhook : ils continuent donc de cloner, et les push lancent toujours des déploiements ; sur leur page **Déploiements**, ils affichent désormais une **URL Git personnalisée**. Si vous supprimez un tel site, retirez vous-même sa deploy key et son webhook chez l'hébergeur Git.

Vimonto Deploy ne révoque pas son accès chez l'hébergeur Git ; pour cela, supprimez aussi l'application OAuth autorisée (ou le token d'accès) chez GitHub, GitLab ou Bitbucket.

## Questions fréquentes

### Ai-je besoin d'une connexion Git pour déployer ?

Non. Vous pouvez aussi déployer depuis une **URL Git personnalisée** : en SSH (`git@…`) pour les dépôts privés, avec la deploy key du site que vous ajoutez vous-même au dépôt, ou en HTTPS pour les dépôts publics. Vous lancez alors les déploiements vous-même ou depuis votre CI avec l'URL de déploiement du site. Consultez [déploiements](https://ops.vimonto.com/docs/fr/sites/deployments).

### Vimonto Deploy peut-il faire un push sur mon dépôt ?

Non. Les deploy keys sont ajoutées en lecture seule : un serveur peut cloner et faire un pull, mais pas un push.

### Vimonto Deploy voit-il tous mes dépôts ?

Avec OAuth, il peut lire tous les dépôts que le compte connecté peut lire ; il ne modifie que les dépôts que vous liez à un site (une deploy key et, avec le déploiement rapide, un webhook). Pour un accès plus restreint, connectez un compte Git distinct n'ayant accès qu'aux dépôts que vous déployez, ou utilisez une URL Git personnalisée.

### Puis-je utiliser des organisations GitHub ?

Oui. La liste des dépôts inclut les dépôts de votre compte et ceux des organisations GitHub dont vous êtes membre, dans la mesure où l'organisation autorise l'application OAuth.

### Que deviennent les dépôts liés quand je transfère un serveur ?

Les connexions restent dans votre organisation. Les sites d'un [serveur transféré](https://ops.vimonto.com/docs/fr/servers/transfer-a-server) perdent leur lien avec la connexion et le déploiement rapide est désactivé ; ils continuent de se déployer depuis leur adresse de dépôt avec leur propre deploy key. La nouvelle organisation peut les lier à l'une de ses propres connexions sur la page **Déploiements** de chaque site.