Configurer un espace de travail
Les cinq sections de la configuration, du nom de l’espace aux variables de chaque environnement, et leurs effets.
Vérifié dans l’application le 5 septembre 2026
Qui peut Administrateur
La configuration est le seul endroit où les réglages d’un espace s’écrivent une fois celui-ci en service. L’assistant fait le même travail une fois, dans l’ordre ; la configuration le refait à froid, section par section, sans ordre imposé. Elle est réservée à l’administrateur de l’espace : les autres rôles sont renvoyés sur l’accueil de l’espace. Tant que GitLab n’est pas connecté, l’onglet mène à l’assistant.
La barre latérale porte cinq sections. Sous chaque nom, une ligne résume l’état : « Connectée » ou « Token expire dans 12 jours », « 6 projets », « 4 branches · 3 env. ». Seule la section Connexion GitLab porte un avertissement, quand le token expire dans moins de trente jours ou qu’il n’y a pas de connexion : c’est la seule panne qui arrête tout l’espace. Sur un petit écran, la barre devient une rangée d’onglets au-dessus du panneau.
Deux sections, Général et Branches et environnements, ont un bouton « Enregistrer » et un badge « Modifications non enregistrées ». Quitter la section ou la page avec des modifications en attente demande confirmation. Dans les trois autres, chaque geste part immédiatement.
Général
Identité, conventions de nommage, clé d’intégration. À droite, deux cartes en lecture : « État de l’espace » (connexion, mode, branche principale, projets, environnements, membres, expiration du token) et « Historique » (créé le, dernière modification).
L’identité
- Nom de l’espace et Description (500 caractères) : ce que voient les membres sur l’accueil et dans l’en-tête.
- Identifiant : immuable, en lecture, mais sélectionnable et copiable. C’est lui qui apparaît dans les URL et les appels d’API.
- Mode de déploiement : en lecture, fixé à la création.
- Branche principale : en lecture, avec un bouton « Changer » qui renvoie vers la section Branches et environnements, où le choix se fait parmi les branches suivies qui ne déploient pas.
- Activer l’écran Fonctionnalités : l’interrupteur du module. Coupé, l’onglet disparaît et le product owner ne peut plus valider ; réactivé, l’écran revient intact.
Les conventions de nommage
Trois cartes, une par écran qu’elles règlent. Chaque motif affiche un exemple résolu sous le champ.
| Carte | Champ | Ce qu’il fait |
|---|---|---|
| Déploiement | Motif du nom de tag | Le nom des tags que Deployer pose. Le jeton {version} est obligatoire, sans lui toutes les versions porteraient le même nom. En mode par branche, {branch} est disponible aussi. |
| Correctifs | Motif de la branche de maintenance | Mode par tag seulement. La branche créée depuis le tag au premier correctif d’une version en service. Jeton {version} obligatoire. |
| Correctifs | Motif de branche de correctif | Le nom proposé pour la branche d’un correctif. Le jeton {issue} est facultatif : remplacé par le numéro de l’issue, retiré quand il n’y en a pas. |
| Correctifs | Nom de branche sans issue | Ce qui remplace {issue} quand aucune issue n’est résolue : trois mots tirés au sort, ou le titre du premier commit retenu. |
| Fonctionnalités | Préfixe des branches de fonctionnalité | Le début du nom des branches que l’écran Fonctionnalités examine, feature/ par défaut. La référence de l’issue est lue sur ce qui suit. |
La clé d’intégration
Un secret pour authentifier les appels entrants vers l’espace, distinct de l’identifiant qui, lui, est public. « Générer une clé » l’affiche une fois ; ensuite elle reste masquée, et « Afficher la clé » la révèle à la demande. « Régénérer » remplace l’ancienne, qui cesse aussitôt de fonctionner ; « Révoquer » la supprime sans en créer d’autre. Chaque geste passe par une confirmation.
Connexion GitLab
L’instance et le token avec lesquels Deployer agit sur vos dépôts. Le formulaire à gauche, la carte d’état et l’aide « Quel token créer ? » à droite.
- Lire l'état
La carte de droite dit si la connexion est opérationnelle, le compte du bot, les scopes lus sur GitLab et la date de la dernière vérification. Un token qui expire dans moins de trente jours est annoncé au-dessus des champs, avec la date : à l’expiration, tout l’espace cesse de fonctionner.
- Tester
« Tester » rejoue la connexion et met la carte d’état à jour. Le verdict est dans la carte, pas seulement dans la notification.
- Remplacer le token
« Remplacer » ouvre l’édition : l’URL de l’instance redevient modifiable aussi, parce que GitLab exige les deux ensemble. « Vérifier et remplacer » teste le nouveau token avant de l’enregistrer ; l’ancien reste actif tant que le nouveau n’est pas validé. Changer d’instance délie les projets et retire les sources d’issues : un identifiant GitLab n’a de sens que sur son instance.
- Supprimer la connexion
Dans la zone sensible en bas. Supprimer la connexion délie tous les projets de l’espace ; les branches suivies sont conservées.
Comptes GitLab personnels (facultatif)
Sous le formulaire, un bloc marqué « Facultatif ». Sans application déclarée, tout ce que Deployer écrit dans GitLab l’est par le compte du token. Avec elle, chaque membre peut rattacher son propre compte GitLab depuis « Mon compte GitLab », et ses correctifs portent alors son nom et ses droits.
- Créer l'application dans GitLab
Copiez l’URL de retour affichée, puis créez une application dans votre groupe GitLab (Groupe, Paramètres, Applications) avec cette URL et la portée
api, rien d’autre :write_repositoryne couvre pas l’API, et les correctifs échoueraient.
- Renseigner l'application
Identifiant de l’application et Secret de l’application tels que GitLab les a fournis. Un secret enregistré n’est plus affiché : laisser le champ vide le conserve, en saisir un nouveau le remplace.
- Choisir le repli
« Agir au nom du bot quand le compte n’est pas rattaché » : activé, un membre sans compte rattaché passe par le token ; désactivé, il ne peut pas créer de correctif tant qu’il n’a pas rattaché son compte.
Projets liés
Deux colonnes : à gauche les dépôts rattachés à l’espace, à droite ceux que le token peut voir sur GitLab.
- Lier : cochez dans la colonne de droite, puis « Lier N projets » dans l’en-tête. Tout ou rien : si GitLab refuse un projet, aucun n’est lié et le fautif est mis en évidence. Un projet déjà lié n’est pas sélectionnable.
- Ordonner : glissez les projets de gauche. L’ordre n’est qu’un ordre d’affichage, rien n’en dépend.
- Synchroniser : relit les métadonnées de tous les projets liés. Un projet en échec est listé, mais reste lié ; c’est à vous de décider de le délier.
- Délier : sur une ligne, derrière confirmation. Le projet redevient disponible à droite. Rien n’est touché sur GitLab.
Les variables de pipeline
Sur les projets récents, GitLab refuse par défaut les variables de pipeline envoyées par une API, et une mise en service en mode par tag échoue alors sur une erreur de droits que rien n’explique. La section le voit avant la panne : un badge « Variables refusées » sur les dépôts concernés, et une alerte au-dessus de la liste avec un bouton « Ouvrir sur N projets » qui lève le réglage, derrière confirmation, là où le bot est Maintainer. Les dépôts où il ne l’est pas sont comptés à part : aucun bouton ne les sauvera, il faut d’abord élargir les droits du bot. Un dépôt marqué « Illisible » n’a pas pu être diagnostiqué ; ce n’est pas une panne de l’écran.
Branches et environnements
La section la plus dense, et la seule qui change de forme selon le mode : « Branches & environnements » en mode par branche, « Environnements » en mode par tag. Une liste à gauche, le détail de la ligne sélectionnée à droite.
La liste
- Ajouter une ligne
Le champ en bas de liste crée une branche suivie en mode par branche, un environnement en mode par tag, et ouvre aussitôt la ligne créée : une branche ajoutée n’est encore rien tant qu’elle n’est pas configurée.
- Ordonner
Glissez les lignes : l’ordre de la liste est l’ordre de promotion.
- Configurer, puis enregistrer
Le panneau de droite se modifie sur plusieurs champs à la fois, puis « Enregistrer » envoie le tout. La barre en tête du détail reste visible en défilant, avec le badge « non enregistré ». Changer de ligne avec des modifications en attente demande confirmation.
Le panneau de détail
Ce qu’il montre dépend de la ligne et du mode.
| Champ | Branche principale | Branche suivie seule | Environnement (par branche) | Environnement (par tag) |
|---|---|---|---|---|
| Nom Git de la branche | oui | oui | oui | non |
| « Cette branche est un environnement de déploiement » | non | oui | oui | non |
| Nom et description de l’environnement | non | non | oui | oui |
| Branches sources autorisées | non | non | oui | non |
| Variables | non | non | oui | oui |
| Étiquettes | non | non | oui | oui |
| Actions | non | non | oui | oui |
| « Définir comme principale » | non | oui | non | non |
| Supprimer | non | oui | oui | oui |
- Nom Git de la branche : la casse compte. Renommer ici ne renomme pas la branche dans vos dépôts, faites-le d’abord côté GitLab. Le nom d’environnement, lui, est un libellé affiché à la place du nom Git dans l’historique.
- Branches sources autorisées (mode par branche) : les branches depuis lesquelles une copie peut partir vers cette cible. Sans aucune source, l’environnement ne peut pas être déployé, et la tuile de l’écran Déploiements le dit.
- Définir comme principale : réservé à une branche suivie qui ne déploie pas, derrière confirmation. Les environnements gardent leurs branches sources.
- Supprimer enlève l’environnement, puis la branche.
Les variables
Des paires clé et valeur, les deux acceptant des jetons. En mode par branche elles sont écrites sur le projet GitLab avant la copie de la branche ; en mode par tag elles sont passées au pipeline de mise en service, et rien n’est laissé sur le projet. La liste des jetons disponibles est affichée sous le bloc, et elle dépend du mode :
| Jeton | Ce qu’il vaut | Mode |
|---|---|---|
{version} | Le numéro de version saisi au déploiement | les deux |
{environment} | Le nom de cet environnement, tel qu’il est saisi | les deux |
{environment_slug} | Le même nom, sans accent ni majuscule, pour ce que GitLab refuse en libellé | les deux |
{date} | L’horodatage du déploiement, au format ISO | les deux |
{description} | La description saisie au déploiement | par branche |
{branch} | La branche cible, celle qui est écrasée | par branche |
{ref} | La branche source, celle qui est copiée | par branche |
{tag} | Le tag mis en service | par tag |
Les étiquettes
Des paires clé et valeur portées par l’environnement, qui donnent à la grille de l’écran Déploiements ses axes de regroupement et de filtre : tenant=acme, region=eu-west-1. Elles ne partent jamais dans un pipeline ; c’est ce qui les distingue des variables, juste au-dessus, et pourquoi le bloc est séparé.
- La clé propose les axes déjà utilisés dans l’espace, pour ne pas créer
tenant,clientetcustomerpour une seule idée. La valeur est libre. - Minuscules, chiffres, point, tiret et souligné seulement. Les majuscules sont minusculées à la frappe ; espaces, accents, virgule et deux-points sont refusés, parce qu’ils rendraient l’URL de filtre ambiguë.
- Un environnement porte au plus une valeur par axe. Retirer la dernière étiquette d’un axe fait disparaître l’axe des contrôles de la grille.
Les actions
Des boutons manuels que l’écran Déploiements affiche dans le panneau de cet environnement : un appel HTTP déclenché à la main, pour reconstruire un index, vider un cache, relancer un service. « Ajouter une action » demande un nom de bouton, une description (affichée dans la confirmation avant de lancer), la méthode, l’URL, des entêtes et un corps envoyé tel quel. L’URL, les entêtes et le corps sont chiffrés et ne sont visibles que des administrateurs. Chaque action affiche son dernier lancement et son issue : réussie, échouée, sans réponse, bloquée. Supprimer une action emporte son historique.
Sources d’issues
Les groupes et projets GitLab où l’écran Correctif cherche les issues quand vous tapez dans son champ. Même forme que Projets liés : déclarées à gauche, disponibles sur GitLab à droite, avec deux onglets, « Groupes » et « Projets ».
- Groupe : couvre tous ses projets en un seul appel. Le choix économique, dès qu’un groupe rassemble vos boards.
- Projet : lui seul. Quand les boards sont éparpillés sous des sous-groupes différents sans parent commun accessible.
- Quinze sources au plus : chacune est un appel GitLab à chaque recherche.
- Un projet déjà lié reste sélectionnable ici : porter des issues et être déployé sont deux rôles indépendants.
Deux sections de plus, selon les modules
La barre latérale gagne une entrée « Assemblage » quand on veut activer la branche assemblée (module, nom de branche, projet orchestrateur, jeton, webhooks : voir La branche assemblée), et une entrée « Intelligence artificielle » pour la rédaction assistée des notes de version : un fournisseur (Anthropic, ou OpenAI et tout backend compatible), une clé d’API, un modèle. « Tester » vérifie la clé sans rien consommer et liste les modèles accessibles ; la clé ne ressort jamais, la remplacer veut dire la resaisir. Sans connexion, la note rédigée reste possible à la main.
Supprimer l’espace
En pied de barre latérale, la zone sensible porte « Supprimer l’espace ». La confirmation demande de retaper le nom. Membres, connexion, branches suivies et environnements partent avec ; rien n’est touché sur GitLab.