Hébergement GitLab
Votre code chez vous, pas chez quelqu’un d’autre
Une instance GitLab qui vous est propre, hébergée sur notre infrastructure nantaise et exploitée par nos équipes. Dépôts, intégration continue et registre d’images, sous le seul droit français et européen.
- Instance dédiée, pas un compte sur une plateforme partagée
- Dépôts, CI/CD et registre d’images au même endroit
- Sauvegardée, mise à jour et supervisée par nos équipes
- Hébergée en France, sous droit français et européen
Le principe
Le code est l’actif le plus sensible d’une entreprise
Ce qu’il y a vraiment dans un GitLab
On y pense comme à un espace de dépôts. C’est en réalité bien davantage : l’historique complet de ce que fait votre produit, les discussions techniques qui expliquent chaque décision, et — le point qu’on oublie — les secrets d’intégration continue. Clés d’API, accès aux serveurs de production, identifiants de base de données : tout cela vit dans les variables de la chaîne de build.
Autrement dit, l’accès à votre GitLab vaut souvent l’accès à votre production. C’est ce qui rend la question de l’endroit où il tourne moins théorique qu’elle n’en a l’air.
Le droit applicable, pas seulement le lieu
Un service opéré par une société soumise à un droit étranger le reste, quelles que soient les machines sur lesquelles il tourne. Pour du code source, des tickets clients et des secrets de production, beaucoup d’organisations — un éditeur, un bureau d’études, un prestataire sous accord de confidentialité — ne peuvent pas se le permettre, ou ne le veulent pas.
Votre instance tourne sur notre infrastructure, à Saint-Herblain, sur du matériel qui nous appartient. Les seules lois qui s’y appliquent sont françaises et européennes.
Un coût qui ne suit pas votre croissance
Les plateformes en ligne facturent par utilisateur et par minute de build. C’est confortable au début, et cela devient le poste qui grimpe le plus vite : chaque embauche coûte un siège, chaque pipeline coûte des minutes, et le budget augmente précisément quand l’équipe produit le plus.
Une instance à vous change la structure du coût : vous payez une machine, pas des sièges. Ajouter un développeur ne change rien, et un pipeline qui tourne dix fois par jour non plus. GitLab est par ailleurs un logiciel libre — vous ne dépendez d’aucune décision d’éditeur sur son prix ou son avenir.
Ce que vous ne faites pas
L’exploitation. Une instance GitLab n’est pas un logiciel qu’on installe et qu’on oublie : elle demande des mises à jour régulières — c’est le chemin par lequel arrivent les correctifs de sécurité — une surveillance des ressources, et des sauvegardes qui soient réellement restaurables.
C’est ce que nous prenons en charge, comme sur nos autres hébergements : installation, mises à jour, supervision, correction automatique sur alerte et administrateur d’astreinte si le problème est plus grave.
L’offre
Ce que couvre l’hébergement
-
Dépôts et revue de code
Vos dépôts Git, les demandes de fusion, les revues et le suivi des tickets — l’usage quotidien de vos équipes, sur une instance qui n’est qu’à vous.
-
Intégration continue
Les pipelines et leurs exécuteurs tournent sur votre instance. Pas de minutes décomptées : la limite est celle de la machine, que l’on dimensionne ensemble.
-
Registre d’images
Le registre intégré héberge vos images de conteneurs à côté du code qui les produit — utile dès que vos déploiements passent par Docker.
-
Sauvegarde et restauration
Sauvegarde quotidienne, conservée 30 jours, répliquée hors du serveur qu’elle protège. Une sauvegarde qui n’a jamais été restaurée n’est qu’une intention.
-
Mises à jour suivies
GitLab publie régulièrement des correctifs de sécurité. Les appliquer fait partie de l’exploitation, pas de votre charge.
-
Supervision et astreinte
Surveillance des ressources, correction automatique sur alerte, administrateur d’astreinte si le problème est plus grave. Support sur un numéro direct non surtaxé.
Questions fréquentes
GitLab hébergé : vos questions
Une autre question ? Le support répond directement, sans intermédiaire, de 9h à 12h et de 14h à 17h.
Pourquoi ne pas rester sur une plateforme en ligne ?
Deux raisons, et elles n’ont rien à voir. Le droit applicable d’abord : un service opéré depuis l’étranger y reste soumis, et votre GitLab contient le code, les discussions techniques et les secrets d’accès à votre production. La structure de coût ensuite : la facturation par utilisateur et par minute de build augmente précisément quand l’équipe produit le plus.
Peut-on migrer notre instance ou notre organisation existante ?
Oui : GitLab dispose d’un mécanisme d’export et d’import qui transporte les dépôts, l’historique, les tickets et les demandes de fusion. Le volume et la version d’origine déterminent la durée réelle de l’opération — nous la regardons avant de nous engager sur un délai.
L’intégration continue est-elle limitée ?
Pas en minutes : les exécuteurs tournent sur votre instance, donc la seule limite est la capacité de la machine. C’est justement ce qu’il faut dimensionner correctement — une chaîne de build est plus gourmande que l’usage quotidien des dépôts, et par à-coups.
Qui applique les mises à jour ?
Nous. GitLab publie régulièrement des correctifs, dont des correctifs de sécurité, et une instance laissée en arrière devient une porte ouverte — d’autant qu’elle donne accès à votre production. L’installation, les mises à jour et la supervision sont à notre charge.
Que se passe-t-il si nous voulons partir ?
Vous partez avec tout. GitLab est un logiciel libre et vos données sont exportables par ses propres mécanismes : ni format fermé, ni dépendance qui rendrait le départ impossible. C’est la même règle que sur nos autres hébergements — les données sont les vôtres.
Et si nous n’avons besoin que de dépôts ?
Alors une instance complète est peut-être surdimensionnée, et nous vous le dirons. GitLab prend tout son sens quand la chaîne de build, le registre d’images et le suivi des tickets vivent au même endroit que le code. Pour du simple stockage de fichiers partagés, c’est vers un autre outil qu’il faut regarder.
Combien de développeurs, et quelle chaîne de build ?
Ces deux réponses suffisent à dimensionner la machine. Décrivez-nous aussi d’où vous venez, si vous migrez une instance existante.