Les notes de version
La note calculée depuis les commits, ses facettes et ses états dégradés, puis la note rédigée, à la main ou assistée.
Vérifié dans l’application le 5 septembre 2026
Une note de version répond à une seule question : qu’est-ce qu’il y a entre ces deux points ? Deployer la calcule depuis GitLab, projet par projet, en comparant les commits entre deux déploiements, puis regroupe les commits par issue. L’écran a deux onglets : Détail, la note calculée, vérifiable, qui fait foi ; et Note rédigée, le document qu’on en tire pour le diffuser, écrit à la main ou avec l’assistance d’un modèle.
Qui peut LecteurProduct ownerDéveloppeurManagerAdministrateur
Tout le monde lit la note calculée et la note rédigée. Rédiger, enregistrer ou réinitialiser la note rédigée, et régler la convention de validation, demandent le rôle de product owner au moins.
Deux lectures, un même écran
L’écran ne s’ouvre jamais depuis la navigation : il n’existe que borné sur une cible, et il se rejoint depuis une ligne de l’écran Versions ou depuis le panneau d’une cible de l’écran Déploiements. Pendant qu’il est ouvert, une pastille à droite de la barre d’onglets porte son titre, avec une croix pour le refermer ; la flèche de l’en-tête fait la même chose.
| Lecture | La question | Les bornes | Bouge-t-elle |
|---|---|---|---|
| Note de version | Qu’est-ce qui est parti dans cette version ? | Deux déploiements : le précédent et celui-ci. | Non, jamais : deux points figés. |
| Évolutions à venir | Qu’est-ce qui attend d’aller sur cet environnement ? | Le déploiement en service et une borne haute : la version choisie, la branche source choisie, ou la branche principale. | Oui, à chaque fusion : la fraîcheur est affichée, « Calculé le ». |
L’en-tête dit contre quoi la note calcule (1.2.0 → 1.2.3, ou 2.14.0 → master) : c’est la seule chose qui distingue une note bornée sur une version d’une note bornée sur la principale. L’adresse de l’écran porte tout ce qui identifie le calcul : un collègue qui la reçoit voit la même note, à condition d’être membre de l’espace. Pour quelqu’un d’extérieur, on envoie un export ou la note rédigée, pas un lien.
Lire la note calculée
Trois niveaux, du plus général au plus fin :
- Le board, le projet GitLab qui porte les tickets, pas celui du code. Une équipe centralise souvent ses issues dans un dépôt de tickets alors que le code vit dans trois autres ; grouper par dépôt de code éclaterait chaque ticket en trois entrées.
- L’issue, l’unité de sens : la référence (lien vers GitLab), le titre, l’état, les étiquettes avec leurs couleurs GitLab, qui l’a créée, et le nombre de commits qui la référencent. Une issue encore ouverte dont le code est parti n’est pas « incomplète » : elle est dans la version, le ticket attend une validation.
- Les commits, repliés : la preuve, pas le propos. Chaque commit porte son dépôt d’origine, et c’est là qu’on voit qu’un ticket a traversé trois dépôts.
En tête de note, un décompte des dépôts lus (« 16 dépôts lus », ou « 14 lus · 1 tronqué · 1 illisible »), avec le détail par dépôt au survol.
Ce qu’une note incomplète dit d’elle-même
Une note qui ment par omission fait perdre confiance dans toutes les autres. Chaque cas dégradé est donc visible.
| Ce que vous voyez | Ce que ça veut dire | Quoi faire |
|---|---|---|
| « Cette note ne dit pas tout », en tête de liste, avec des projets nommés | Un dépôt n’a pas pu être lu (branche ou tag absent, panne GitLab), ou GitLab a tronqué la liste de ses commits. « Ce projet n’a rien changé » et « ce projet n’a pas pu être lu » ne sont pas la même chose. | Lire les autres projets, qui restent exacts. Vérifier le dépôt nommé dans GitLab avant de signer une mise en production. |
| Références introuvables | L’issue n’existe plus, la référence est mal orthographiée dans un commit, ou le token de l’espace ne voit pas le board. L’issue reste affichée avec sa référence brute et ses commits. | Un « ticket inaccessible » massif signale un token aux droits trop étroits, à corriger dans la configuration. Un « ticket introuvable » isolé est une faute de frappe, qu’on ne corrigera pas. |
| Commits sans issue | Les commits qu’aucune référence ne réclame, en pied de note, repliables mais jamais absents. | C’est ce qui rend la note vérifiable : 12 issues couvrent-elles 40 commits ou 400 ? Une section qui grossit dit qu’une équipe a cessé de référencer ses tickets. |
| Correctifs non reportés, en rouge | Des commits présents sur la branche de l’environnement et absents de sa source : un correctif appliqué sur prod et jamais reporté sur la principale. Il sera perdu au prochain déploiement. | Reporter le correctif. Le nom de l’auteur est là pour savoir à qui demander. Mode branche et évolutions à venir seulement. |
| « Aucun changement entre ces deux points. » | Deux déploiements consécutifs portent la même version : redéploiement après incident, retour arrière. La note est légitimement vide. | Rien. À ne pas confondre avec un filtre qui ne rend rien, qui propose de réinitialiser. |
Filtrer sans changer ce que la note affirme
Le même rail de facettes que Fonctionnalités, à gauche : Contenu (issues, références introuvables, commits sans issue, correctifs non reportés), Boards, État de l’issue, Créateur, Assigné, Labels GitLab (OU dans une portée, ET entre portées, comme dans GitLab) et Dépôt de code. Ce dernier axe est propre à cet écran : « qu’est-ce qui a bougé dans api dans cette version ? ». Une issue est retenue dès qu’un de ses commits vient du dépôt coché, et reste affichée entière.
La convention de validation
Qui peut Product ownerDéveloppeurManagerAdministrateur
Une équipe a souvent une règle : une issue ne part pas tant qu’elle porte Status::To Test, ou tant qu’elle est ouverte. Deployer ne la devine pas : elle est désarmée par défaut, et se règle depuis le bouton bouclier de l’en-tête, « Convention de validation », par ceux qui connaissent la règle de leur équipe. C’est une convention d’espace, pas une préférence personnelle : deux personnes ne peuvent pas lire deux vérités sur la même livraison.
- Régler la convention
Cochez les labels GitLab surveillés parmi ceux de la note ouverte, ou saisissez un nom absent ; armez ou non l’alerte sur les issues encore ouvertes. Les labels déjà surveillés restent listés même absents de la note, pour pouvoir les retirer.
- Lire l'alerte
Armée, la convention marque chaque issue concernée d’un bord ambre, ajoute un badge « N à valider » sur l’en-tête de son board, et pose un bandeau en tête de liste : « 5 issues pas encore validées dans ce qui reste à partir » sur les évolutions à venir, « 2 issues sont parties sans être validées » sur une version livrée. « Ne voir que celles-là » coche l’axe « À valider » du rail. Le bandeau rappelle la règle à côté de son verdict.
Exporter et rafraîchir
« Exporter » propose Markdown ou Excel, générés par le serveur, toujours sur la note complète. « Copier » met le markdown dans le presse-papier. « Rafraîchir » relance le calcul, en repassant par l’écran d’attente : une note coûte des dizaines d’appels GitLab, plusieurs secondes sur un espace chargé, et elle n’est jamais relue toute seule. Une note de version livrée est gardée en mémoire une heure côté serveur : la deuxième ouverture est instantanée, c’est le cas normal d’un lien partagé.
La note rédigée
Qui peut Product ownerDéveloppeurManagerAdministrateur
La note calculée est un calcul, immuable et vérifiable. La note rédigée est un document : ce qu’on en dit, à un chef de produit, à un client, dans un ticket de mise en production. Elle est enregistrée, relue, et se rouvre sans toucher à GitLab. Elle ne remplace jamais la note calculée, qui reste dans l’onglet Détail et reste ce que les exports rendent.
L’onglet dit son état sans qu’on l’ouvre : rien, une marque verte quand une note relue existe, une marque pleine quand un jet attend une décision. Le document existe dans chaque langue séparément, et la barre de langue en tête dit lequel on regarde.
Écrire à la main
- Partir du texte calculé
Tant que rien n’est enregistré, l’onglet montre le markdown calculé, réduit aux titres d’issues (ni commits, ni chemins, ni auteurs), marqué « Texte brut, calculé : pas encore relu ».
- Modifier
« Modifier » ouvre un éditeur markdown, avec le rendu à côté. Le markdown est le livrable : ce qui est copié est exactement ce qui est tapé. « Enregistrer » conserve le texte, avec la date de relecture ; « Réinitialiser » supprime le texte, derrière confirmation, dans la langue affichée seulement.
- Copier ou télécharger
« Copier » et « Télécharger » (un fichier
.mdnommé d’après les bornes) sont dans le pied de l’écran, et suivent l’onglet actif : sur Détail ils rendent la note calculée, sur Note rédigée le texte relu.
Rédiger avec l’assistance d’un modèle
Quand l’administrateur de l’espace a configuré une connexion à un fournisseur d’intelligence artificielle (Configuration, section « Intelligence artificielle » : un fournisseur, une clé, un modèle, testables sans rien consommer), la colonne « Rédaction assistée » s’ouvre à droite du document. Sans connexion, elle dort et le dit ; la note rédigée à la main reste entière.
On n’écrit aucun prompt : on compose des axes, on lit, on retouche.
- Composer les axes et réécrire
Audience (technique, produit, client), longueur (standard ou court, qui veut dire moins d’entrées, pas des lignes plus courtes), regroupement (par board ou par thème), références (complètes, courtes, aucune), emoji, et un complément libre d’une phrase ou deux. « Réécrire » produit un jet en quelques secondes ; l’avancement dit sa phase. Rien n’est enregistré : la note précédente est intacte.
- Retoucher
Un jet n’est presque jamais bon du premier coup. Les retouches reprennent le texte affiché au lieu de repartir des tickets : plus court, moins technique, regrouper par thème, retirer le jargon interne, ton plus formel, ou une phrase à vous (« ne traduis pas board »). Les jets de la séance sont conservés dans un fil, et on peut revenir à l’un d’eux tant qu’on ne quitte pas l’écran.
- Enregistrer ou abandonner
Un jet en attente n’offre que sa décision : « Enregistrer » en fait la note rédigée que l’équipe voit ; « Abandonner » ne change rien. La note enregistrée garde la trace de sa génération : le modèle, les axes, les jetons consommés. Corriger ensuite ce texte à la main en fait un texte écrit à la main.
- Reprendre la note dans l'autre langue
Une note relue en français, dont on veut l’anglaise : en basculant sur une langue vierge, une carte propose « Reprendre cette note ». Ce n’est pas une traduction mot à mot : les arbitrages (ce qui est gardé, le plan, le ton) traversent, et la note est rédigée dans la langue cible. La carte ne se propose jamais dans l’autre sens sur une note déjà écrite pour elle-même.
