Intégrer GitLab à votre système d'information
Plateforme DevOps complète : gestion de code source, CI/CD, issues, wiki. Disponible en SaaS et self-managed.
Équipes de développement, DevOps, DSI, éditeurs de logiciels.
Pourquoi intégrer GitLab
GitLab est une plateforme DevOps complète qui couvre le cycle de vie du développement : gestion de code source, intégration continue, déploiement, issues et wiki. L'intégration avec un CRM crée un lien entre les demandes clients et leur réalisation technique.
Le cas d'usage central est la synchronisation des demandes. Un client signale un problème ou demande une évolution. Le ticket CRM est créé par le support. Le connecteur crée une issue GitLab dans le projet concerné. L'équipe de développement travaille dans GitLab. Le support et le commercial suivent l'avancement dans le CRM.
GitLab expose deux API : REST et GraphQL. L'API REST est complète et bien documentée, couvrant tous les objets GitLab. L'API GraphQL permet des requêtes plus efficaces pour récupérer des données liées. L'authentification se fait par token personnel ou token d'application OAuth2.
Les webhooks GitLab notifient les événements en temps réel : création d'issue, commentaire, changement de statut, merge request, pipeline, release. Le connecteur reçoit ces notifications et met à jour le CRM en conséquence. Le support voit immédiatement quand un bug est corrigé.
Le suivi des merge requests est un cas d'usage avancé. Une issue GitLab est souvent liée à une ou plusieurs merge requests. Le connecteur peut suivre le cycle : MR créée, en revue, mergée, déployée. Le ticket CRM reflète cet état. Le commercial sait que la fonctionnalité est "en cours de revue" ou "déployée en production".
GitLab est disponible en SaaS (gitlab.com) et en version self-managed (auto-hébergée). La version SaaS est directement accessible. La version self-managed nécessite d'exposer l'API de manière sécurisée : reverse proxy avec authentification, VPN, ou agent de synchronisation local.
Le volume d'événements peut être important sur un GitLab actif. Le connecteur doit filtrer les événements pertinents : seuls certains projets, seules les issues avec certains labels, ignorer les pipelines CI. Cette configuration évite de surcharger le CRM avec des données non pertinentes.
Schémas d'intégration
Synchroniser les tickets support CRM avec les issues GitLab
Remonter l'état des merge requests dans le CRM
Créer des issues GitLab depuis les demandes clients
Notifier les commerciaux des releases et corrections
Alimenter le reporting client avec les métriques DevOps
Points de vigilance
GitLab self-managed nécessite une exposition sécurisée de l'API.
Les droits d'accès aux projets déterminent ce que l'intégration peut voir.
Les labels, milestones et boards sont personnalisables par projet.
Le volume d'événements peut être élevé : filtrer les webhooks pertinents.
Comment nous procédons
Chaque synchronisation que nous livrons est une unité autonome : un sens, un déclencheur. Une synchronisation dans les deux sens correspond donc à deux unités distinctes, ce qui permet d'en interrompre une sans casser l'autre et de lire les journaux sans ambiguïté.
Nous commençons par un cadrage qui tranche quatre points : la clé de rapprochement entre les deux systèmes, le comportement attendu lorsque plusieurs correspondances sont trouvées, les champs obligatoires côté destination qui n'ont pas de source, et la désignation d'une source de vérité champ par champ — pas objet par objet.
Le développement est suivi d'une recette en mode simulation : le flux lit les données réelles et enregistre ce qu'il aurait écrit, sans rien modifier. Cette étape est systématique et conditionne la mise en service.
Les flux sont ensuite hébergés et supervisés sur notre plateforme, avec reprise automatique en cas d'échec passager et alerte en cas d'échec persistant.
Questions fréquentes
Pourquoi connecter GitLab à un CRM ?
Pour donner une visibilité aux équipes non techniques sur l'avancement des développements. Le support voit si le bug signalé est corrigé, le commercial sait quand la fonctionnalité demandée sera livrée, sans accéder à GitLab.
Comment fonctionne l'API GitLab ?
GitLab expose une API REST complète et une API GraphQL. L'authentification se fait par token personnel ou token d'application. Les endpoints couvrent les projets, issues, merge requests, pipelines, releases, etc.
Comment synchroniser tickets CRM et issues GitLab ?
Le connecteur crée une issue GitLab quand un ticket CRM est qualifié comme demande technique. L'URL de l'issue est stockée dans le CRM. Les changements de statut et labels GitLab sont répercutés. Le support voit l'avancement sans quitter le CRM.
Peut-on suivre les merge requests ?
Oui. Les webhooks GitLab notifient les événements de merge request : création, revue, merge, fermeture. Le CRM peut afficher l'état de la MR associée à un ticket. Le commercial sait si le code est en revue, mergé ou déployé.
Comment gérer les releases ?
Les releases GitLab peuvent être associées aux issues (via milestones). Quand une release est publiée, le connecteur peut mettre à jour tous les tickets CRM dont les issues sont incluses. Une notification informe les parties prenantes.
GitLab self-managed : comment exposer l'API ?
Via un reverse proxy avec authentification (VPN, IP whitelist, certificat client). L'API doit être accessible depuis le connecteur cloud. Une alternative est un agent local qui synchronise les données vers un intermédiaire.
Comment filtrer les événements webhook ?
GitLab permet de configurer les événements déclencheurs par projet. Le connecteur peut aussi filtrer côté réception : ne traiter que les issues avec certains labels, ignorer les projets non liés au CRM, etc.
Pour aller plus loin
Comprendre l'intégration
Besoin de connecter GitLab ?
Décrivez-nous votre besoin. Nous vous répondons sous 48 heures avec une première analyse.