meta données pour cette page
  •  

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision		Révision précédente
certif:procedure:develop:proceduremiseenligne:logeas-web [2026/08/03 15:53] – nicolascertif:procedure:develop:proceduremiseenligne:logeas-web [2026/09/30 10:33] (Version actuelle) – nicolas
Ligne 1: Ligne 1:
-====== Cycle de release LoGeAsWeb ======+|{{:undo-2.svg?30|}} [[certif:dm#gestion_des_versions|Retour au dossier de maintenance]]|| 
 +|{{:connexe.jpg?40|}} **Sujets connexes**|[[https://cartographie-fonctionnelle.logeas-web.fr/|Cartographie fonctionnelle de LoGeAs]]\\ [[https://cartographie-fonctionnelle.logeas-web.fr/RapportsVersion|Informations sur la version en cours]]\\ [[certif:procedure:develop:gestionversion]]\\ [[certif:procedure:develop:chainequalificationlivraison]]\\ [[certif:procedure:develop:proceduremiseenligne]]\\ [[certif:procedure:develop:gestionversionpratique]]|
  
-//Document de référence — pièce du dossier de certification qualité NF Logiciel.// +====== Proc#169 - Cycle de release LoGeAs Web ======
-//Périmètre : dépôt ''logeas-web'' (front-end Angular). Dernière mise à jour : 2026-08-03.//+
  
-Ce document décrit le dispositif maîtrisé de publication de LoGeAsWeb : de la sauvegarde du travail individuel jusqu'à la livraison d'une version au client. Il a vocation à servir de pièce justificative démontrant un processus de release reproductible, tracé et outillé de garde-fous automatiques, conformément aux exigences de maîtrise du cycle de vie logiciel attendues dans le cadre de la certification NF Logiciel.+===== Informations qualité =====
  
-----+^Suivi des modifications majeures^^^ 
 +^Date^Auteur^Modifications^ 
 +|3 août 2026|Nicolas MARCHAND|Création du document| 
 +|30 septembre 2026|Nicolas MARCHAND|Alignement sur la chaîne de qualification et de livraison (Proc#168) : la livraison est faite par les scripts ''livrer-beta'' et ''livrer-release'' derrière les portes bloquantes, ajout de la qualification et de la recette, suppression de la release sans beta ; mise au format de la maîtrise documentaire|
  
-===== 1. Contexte et objectifs =====+|**Suivi des approbations** |[[https://cartographie-fonctionnelle.logeas-web.fr/UniversProcedure?id=169|Cartographie fonctionnelle – fiche de la procédure]]| 
 +|**Objet** |Décrire le dispositif technique de gestion des versions et de publication de LoGeAs Web, depuis l'intégration des développements jusqu'à la production des versions destinées aux utilisateurs, pour les dépôts ''logeas-web'' et, lorsque nécessaire, ''logeas-lib''.| 
 +|**Destinataires** |**- Validation des modifications :** Gérant \\ **- Approbation du document :** Équipe développement|
  
-==== 1.1 Constat avant formalisation ====+\\
  
-Avant la mise en place de ce dispositif, le cycle de publication reposait entièrement sur des gestes manuels, variables selon la personne et le moment :+===== 1. Objet et périmètre =====
  
-  * Aucun garde-fou automatique : rien n'empêchait de poser un tag de release sur un build cassé ou avec des tests en échec. +Ce document décrit le dispositif technique de gestion des versions et de publication de LoGeAs Web : les scripts, les fichiers produits, le calcul des numéros de version et les éléments de preuve.
-  * Dérive silencieuse du numéro de version : ''package.json'' était resté bloqué à ''11.0.23'' alors que la branche de développement en cours s'appelait déjà ''11.0.25'', sans que cet écart soit détecté. +
-  * Aucune isolation des builds de test : la configuration de build ne permettait de générer que vers le dossier de livraison client (''LogeasWeb''), y compris pendant une phase de test — aucun dossier ''LogeasWeb-Test'' distinct n'était réellement alimenté. +
-  * Convention de tag non fiabilisée : coquille orthographique reproduite sur plusieurs tags historiques (''realease'' au lieu de ''release''). +
-  * Absence de traçabilité fine des fusions : les commits de fusion ne portaient qu'un titre générique, sans lister les commits réellement intégrés.+
  
-==== 1.2 Objectifs du dispositif ====+Il complète les documents suivants :
  
-  * **Traçabilité** : chaque étape clé (intégration, beta, release) laisse une trace exploitable (commit détaillé, tag Git, fichier ''version.ts'' embarquant branche/commit/date de build). +  * [[certif:procedure:develop:gestionversion|Proc#145 - Procédure de gestion des versions]] : règles générales de versionnage et d'identification des versions. 
-  * **Reproductibilité** : les mêmes étapes techniques sont exécutées de la même façon à chaque cycle, indépendamment de la personne qui les déclenche. +  * [[certif:procedure:develop:chainequalificationlivraison|Proc#168 - Chaîne de qualification et de livraison]] : déroulé pas à pas, responsabilités, qualification, validation, recette et portes bloquantes. 
-  * **Garde-fous automatiques** : impossible de publier une beta ou une release sur un code qui ne compile pas ou dont les tests échouent. +  * [[certif:procedure:develop:gestionversionpratique|Guide pratique de gestion des versions]] : mode opératoire destiné aux développeurs.
-  * **Séparation stricte des environnements de sortie** : un build de test n'atterrit jamais dans le dossier destiné au client, et réciproquement. +
-  * **Discipline de numérotation** : un numéro de version publié doit pouvoir être retrouvé sans ambiguïté dans l'historique Git, sans numéro « orphelin » ni collision.+
  
-----+**En cas de divergence entre ce document et Proc#168 sur le déroulé d'une livraison, Proc#168 fait foi.** Le présent document explique comment le dispositif fonctionne ; il ne remplace ni les décisions de validation ni les contrôles de qualification.
  
-===== 2. Vue d'ensemble du cycle =====+===== 2. Objectifs =====
  
-Le cycle se déroule en 4 étapes séquentielles. Seules les étapes 2 à 4 correspondent à une procédure outillée (une commande dédiée, exécutée via l'assistant Claude Code) ; l'étape 1 reste volontairement manuelle. Aucune des procédures outillées ne crée de nouvelle branche Git pour la beta ou la release : elles posent un simple repère (tag) sur la branche de version, conformément à la pratique déjà en usage dans l'équipe.+Le dispositif de release a pour objectifs :
  
-{{ :certif:procedure:develop:proceduremiseenligne:cycle-release-schema.svg | Schéma des 4 étapes du cycle de release LoGeAsWeb}} +  * **Reproductibilité** : exécuter les opérations techniques selon une procédure identifiée et maîtrisée. 
-NB : SVG stocké sur le wiki éditable par exemple avec Inkscape+  * **Traçabilité** : relier chaque version publiée à son code source, à ses commits et aux résultats des contrôles. 
 +  * **Sécurisation** : empêcher la production d'une livraison lorsque les contrôles obligatoires ne sont pas satisfaits. 
 +  * **Séparation des environnements** : distinguer les versions de test des versions destinées aux utilisateurs. 
 +  * **Maîtrise du versionnage** : éviter les collisions, les incohérences et les versions non identifiables. 
 +  * **Conservation des preuves** : permettre de retrouver les informations nécessaires à la justification d'une livraison.
  
-^ Étape ^ Type ^ Déclencheur ^ Résultat ^ +===== 3. Architecture générale du cycle =====
-| 1. Travail personnel | Manuel | En continu pendant le développement | Sauvegarde de l'avancement sur une branche personnelle | +
-| 2. fusion-dev | Outillée | Travail perso jugé prêt à intégrer | Intégration à la branche de version commune, 1ère vérification technique du cycle, log complet des commits fusionnés | +
-| 3. release-beta | Outillée | Branche de version jugée stable pour test interne | Build déposé dans ''LogeasWeb-Test'', tag ''X.Y.Z.W_beta'' | +
-| 4. release-client | Outillée | Beta validée (ou release directe si pas de beta jugée nécessaire) | Build déposé dans ''LogeasWeb'', tag ''X.Y.Z_release'' |+
  
-Le passage d'une étape à l'autre reste une décision humaine (quand fusionner, quand passer en beta, quand livrer). Les procédures exécutent les vérifications techniques une fois la décision prise ; elles ne la prennent pas à la place de l'équipe.+Le cycle de publication suit les huit étapes de la chaîne de qualification et de livraison (Proc#168) :
  
-----+^ Étape ^ Opération ^ Outil ^ Résultat ^ 
 +| 1 | Travail personnel puis intégration | ''/fusion-dev'' | Code intégré et contrôlé sur la branche de version | 
 +| 2 | Qualification | ''scripts\qualifier-version.bat'' | Rapport qualité de la version candidate, en brouillon | 
 +| 3 | Validation du rapport qualité | carto, écran « Rapports de version » | Rapport validé (avec ou sans réserves) et publié | 
 +| 4 | Beta | ''scripts\livrer-beta.bat'' | Version de test construite, taguée, avec son rapport de release | 
 +| 5 | Déploiement sur le serveur de test | copie manuelle | Beta disponible pour la recette | 
 +| 6 | Recette de la beta | carto, écran « Rapports de version » | Recette conforme ou non conforme | 
 +| 7 | Release client | ''scripts\livrer-release.bat'' | Version de production construite et taguée | 
 +| 8 | Déploiement client | copie manuelle | Version en ligne |
  
-===== 3. Détail des procédures =====+Deux **portes bloquantes** encadrent les livraisons : la porte beta (avant l'étape 4) et la porte release (avant l'étape 7). Elles sont décrites dans Proc#168.
  
-==== 3.1 Étape 1 — Travail personnel (manuel) ====+Le passage d'une étape à l'autre reste une décision humaine. L'automatisation réalise les opérations et les contrôles prévus, mais ne décide pas de la pertinence fonctionnelle d'une livraison.
  
-**Déclencheur :** en continu, à chaque fois qu'on veut sauvegarder son avancement personnel, sans que le travail soit terminé.+**Rôle des commandes de l'assistant Claude Code.** ''/fusion-dev'' réalise l'intégration. ''/qualifier-version'', ''/release-beta'' et ''/release-client'' **ne livrent rien elles-mêmes** : elles vérifient les préconditions ou la porte, expliquent ce qui bloque, puis renvoient vers les scripts ci-dessus, lancés par le développeur.
  
-**Description :** chacun committe et pousse sa branche personnelle à sa propre façon. Aucune commande dédiée, aucune vérification imposée à ce stade (le code peut très bien ne pas compiler ou casser des tests — ce n'est pas grave puisque c'est encore un travail individuel non intégré).+**Il n'y a pas de release client sans beta recettée** : la porte release l'exige. La seule exception est la procédure d'urgence (Proc#168, cas 8), qui produit une version affichée « Version non qualifiée » et doit être régularisée.
  
-**Justification du choix de ne rien outiller ici :** imposer un build/tests/lint à chaque sauvegarde intermédiaire ralentirait inutilement un geste censé être rapide et fréquent. Le premier point de contrôle réel du dispositif est l'intégration (étape 2).+===== 4. Organisation des dépôts et des environnements =====
  
-**Non couvert par cette étape :** aucune fusion vers le travail commun de l'équipe — c'est l'objet de l'étape suivante.+==== 4.1 Dépôts ====
  
----+Le cycle concerne principalement les dépôts suivants :
  
-==== 3.2 Étape 2 — fusion-dev (procédure outillée) ====+^ Dépôt ^ Rôle ^ 
 +| ''logeas-web'' | Interface Angular LoGeAs Web et scripts de qualification et de livraison | 
 +| ''logeas-lib'' | Bibliothèques Angular partagées utilisées par les interfaces | 
 +| ''logeas-cartographie'' | Cartographie fonctionnelle : écran « Rapports de version » (validation des rapports qualité, recette) |
  
-**Déclencheur :** le travail sur la branche personnelle est jugé prêt à être intégré au tronc commun de la version en cours de développement.+Les bibliothèques de ''logeas-lib'' sont utilisées par ''logeas-web'' sous forme de paquets construits. Le changement de branche ne suffit donc pas à garantir la cohérence des dépendances : les paquets installés doivent correspondre au code de la bibliothèque. C'est pourquoi la qualification reconstruit et réinstalle ''logeas-lib'', et pourquoi les portes vérifient que les paquets installés sont toujours ceux du run qualifié.
  
-**Étapes détaillées :**+==== 4.2 Environnements de génération ====
  
-  - **Identification de la branche cible** : la branche de version numérotée actuellement en développement (à ce jour ''11.0.25''), et non ''develop'' — les cycles récents fusionnent en cascade d'une branche numérotée à la suivante (''11.0.24'' → ''11.0.25''). En cas de doute sur la branche d'intégration courante, la question est posée explicitement plutôt que devinée. +Les builds sont générés localement sur le poste de développement.
-  - **Mise à jour** : ''git fetch'', ''git checkout <branche-de-version>'', ''git pull'' pour être à jour avec ''origin'' avant de fusionner. +
-  - **Fusion avec log complet** : récupération de la liste complète des commits qui vont être intégrés (''git log <branche-de-version>..<branche-perso> --pretty=format:"- %s (%h)"''), puis ''git merge --no-ff <branche-perso>'' avec un message de commit étoffé : le titre standard (''Merge branch 'X' into Y'') suivi en corps de commit de la liste des commits récupérée. Le commit de fusion porte ainsi à lui seul la trace complète de ce qui vient d'être intégré. En cas de conflit à portée métier (logique applicative, pas juste du formatage), validation humaine systématique avant de trancher. +
-  - **Vérification post-fusion** : ''ng build'', ''npm test'' et ''npm run lint'' relancés **sur la branche de version après fusion** — l'intégration de plusieurs travaux peut faire apparaître des problèmes invisibles avant fusion. C'est la première vérification technique réelle du cycle. +
-  - **Publication** : si tout passe, ''git push'' de la branche de version, log complet inclus. Si un problème est détecté, la publication est bloquée jusqu'à correction (ou ''git revert'' du merge si le problème est trop complexe à traiter dans la foulée).+
  
-**Garde-fous :** jamais de ''push --force'' sur cette branche (partagée par toute l'équipe) ; jamais de publication si le build échoue ou si des tests échouent.+^ Destination ^ Usage ^ 
 +| ''D:\Developpements\VersionPublic\LogeasWeb-Test\browser\'' | Version beta destinée aux tests | 
 +| ''D:\Developpements\VersionPublic\LogeasWeb\browser\'' | Version destinée à la production |
  
-**Sortie :** branche de version à jour, intégrée, vérifiée, avec un historique de fusion exhaustif.+La séparation des destinations est assurée par les configurations Angular :
  
----+  * ''production,beta'' pour la génération beta ; 
 +  * ''production'' pour la génération client.
  
-==== 3.3 Étape 3 — release-beta (procédure outillée) ====+Cette séparation évite qu'une génération de test écrase directement les fichiers de production.
  
-**Déclencheur :** la branche commune de la version en cours est jugée stable et prête pour une phase de test/validation interne.+==== 4.3 Déploiement ====
  
-**Étapes détaillées :**+La génération des fichiers et leur déploiement sur les serveurs sont deux opérations distinctes.
  
-  - **État des lieux** : vérification que la branche de version est propre (rien en attente non commité) et à jour avec ''origin''. Si des changements traînent, ils sont d'abord traités via l'étape 2 — cette procédure ne fait pas de fusion. +Le transfert vers les serveurs de test et de production est réalisé manuellement, par une personne disposant des accès nécessaires au bureau à distance.
-  - **Build** : ''npm run build:beta'', qui enchaîne ''prebuild:beta'' (''node scripts/version.js beta'' — voir section 4 pour la règle de numérotation, régénération de ''src/assets/version.ts'' avec branche/commit/date, régénération de la licence DevExtreme) puis ''ng build --configuration production,beta''. La configuration Angular ''beta'' route la sortie vers ''D:/Developpements/VersionPublic/LogeasWeb-Test/'' au lieu de ''LogeasWeb/'' — seule différence technique avec un build release, le reste (optimisations, ''environment.prod.ts'') est identique à la configuration ''production''. Un build cassé bloque systématiquement la suite. +
-  - **Commit du bump de version** : le bump (''package.json'' + ''src/assets/version.ts'') est commité séparément du contenu fonctionnel, message du type ''Preparation version X.Y.Z.W''. +
-  - **Tag** : tag annoté ''X.Y.Z.W_beta'' sur ce commit, poussé vers ''origin'' avec le commit.+
  
-**Garde-fous :** jamais de tag sur un build cassé ; jamais de ''push --force''.+Les scripts de livraison ne réalisent pas eux-mêmes ce transfert.
  
-**Sortie :** build compilé/optimisé déposé dans ''D:\Developpements\VersionPublic\LogeasWeb-Test\browser\'', tag Git correspondant pour toute l'équipe.+===== 5. Description technique des étapes =====
  
-**Hors périmètre :** le déploiement vers le serveur de test réel reste **manuel** — ''LogeasWeb-Test'' n'est qu'un dossier intermédiaire local, à copier à la main vers le serveur (accessible uniquement en bureau à distance, sans accès réseau direct depuis le poste de développement).+==== 5.1 Travail personnel ====
  
----+Chaque développeur travaille sur une branche personnelle issue de la branche de version concernée.
  
-==== 3.4 Étape 4 — release-client (procédure outillée) ====+Les commits et les sauvegardes de cette branche restent libres, afin de ne pas imposer les contrôles de publication à chaque sauvegarde intermédiaire.
  
-**Déclencheur :** la beta correspondante a été validée (ou, si aucune phase beta n'est jugée nécessaire, directement depuis la branche de version), pour produire la version destinée à être livrée au client.+Cette étape ne constitue pas une intégration validée et ne garantit pas que le code compile ou que les tests passent.
  
-**Étapes détaillées :**+Le premier contrôle technique obligatoire du cycle intervient lors de l'intégration.
  
-  - **État des lieux** : vérification que la branche de version est propre et à jour. Si cette release fait suite à une beta, vérification que rien d'autre que des correctifs ciblés n'a été ajouté depuis le tag ''_beta'' correspondant (''git log <tag_beta>..HEAD'') — sinon un nouveau cycle beta est recommandé avant la release client. +==== 5.2 Intégration : /fusion-dev ====
-  - **Build** : ''npm run build'', qui enchaîne ''prebuild'' (''node scripts/version.js release'') puis ''ng build --configuration production''. La configuration ''production'' route déjà la sortie vers ''D:/Developpements/VersionPublic/LogeasWeb/'' (comportement par défaut de ''outputPath'' dans ''angular.json''), pas de configuration supplémentaire nécessaire ici. Un build cassé bloque systématiquement la suite. +
-  - **Commit du bump de version** : commit séparé du bump (''package.json'' + ''src/assets/version.ts''), message du type ''Preparation version X.Y.Z''. +
-  - **Tag** : tag annoté ''X.Y.Z_release'' sur ce commit (orthographe correcte, contrairement aux anciens tags ''_realease''), poussé vers ''origin'' avec le commit.+
  
-**Garde-fous :** jamais de tag sur un build cassé ; jamais de ''push --force''.+La commande ''/fusion-dev'' intègre les développements personnels à la branche de version commune.
  
-**Sortie :** build compilé/optimisé déposé dans ''D:\Developpements\VersionPublic\LogeasWeb\browser\'', tag Git correspondant.+Elle réalise les opérations suivantes :
  
-**Hors périmètre :** le déploiement vers le serveur client reste **manuel**, pour la même raison d'accès que la beta (bureau à distance uniquement).+  * récupération des informations du dépôt distant ; 
 +  * sélection et mise à jour de la branche de version cible ; 
 +  * identification des commits à intégrer ; 
 +  * fusion de la branche personnelle ; 
 +  * constitution d'un message de fusion contenant la liste des commits intégrés ; 
 +  * vérification du code après fusion ; 
 +  * publication de la branche commune si les contrôles sont satisfaisants.
  
-----+Les contrôles techniques portent sur :
  
-===== 4. Numérotation des versions =====+  * la compilation Angular ; 
 +  * les tests unitaires ; 
 +  * l'analyse statique et le lint.
  
-==== 4.1 Règle ====+Les résultats sont examinés avant la publication de la branche commune.
  
-Le numéro de version comporte 3 ou 4 chiffres selon le type de génération :+En cas d'échec, la procédure ne doit pas publier une intégration non validée. En cas de conflit métier ambigu, une décision humaine est nécessaire.
  
-  * Une **beta** ajoute un **4ᵉ chiffre** (''X.Y.Z.W'') qui numérote les tentatives de beta successives au sein d'un même cycle, sans jamais toucher au ''X.Y.Z'' tant qu'aucune release n'a eu lieu. +La procédure n'utilise pas de ''push --force'' sur la branche commune.
-  * Si le nom de la branche de version ressemble à un numéro (ex. ''11.0.25'') et qu'il est supérieur au ''X.Y.Z'' actuellement dans ''package.json'', la première beta du cycle saute directement dessus (rattrapage, sans incrément) et démarre à ''W=1''. Ce mécanisme corrige toute dérive entre le nom de la branche et le numéro réellement utilisé par les builds. +
-  * Une **release** repasse en 3 chiffres en retirant simplement le ''W''. Elle **reprend le même ''X.Y.Z''** que les betas de son cycle : un numéro ''X.Y.Z'' ne doit jamais rester « orphelin », c'est-à-dire utilisé par des betas sans jamais être publié comme release. +
-  * Le 3ᵉ chiffre n'est incrémenté par une release que si ce ''X.Y.Z'' a déjà été publié par une release antérieure (vérification automatique par consultation des tags Git existants, cas d'une relivraison sans nouvelle beta — par exemple un correctif urgent republié depuis la même branche).+
  
-Cette règle garantit qu'il n'existe jamais de numéro de version « perdu » : tout numéro utilisé par une ou plusieurs betas devient, sauf collision, le numéro de la release qui les conclut.+**Résultat attendu :** une branche de version intégrée, contrôlée et accompagnée d'un historique de fusion exploitable.
  
-==== 4.2 Implémentation technique ====+==== 5.3 Qualification : qualifier-version ====
  
-La règle est implémentée dans ''scripts/version.js'' (fonction ''resolveNextVersion''), invoquée avec le mode ''beta'' ou ''release'' selon le script npm utilisé :+Le script ''scripts\qualifier-version.bat'' produit le rapport qualité de la prochaine version, sur un code identifié sans ambiguïté.
  
-<code javascript> +Il réalise les opérations suivantes :
-function resolveNextVersion(currentVersion, branchName, mode) { +
-  const [x, y, z, w] = parseVersion(currentVersion); +
-  const current = [x, y, z]; +
-  let target = current;+
  
-  const branchMatch = /^(\d+)\.(\d+)\.(\d+)$/.exec(branchName); +  * vérification des préconditions sur ''logeas-web'' et ''logeas-lib'' : branche de version, aucune modification locale, branche à jour et poussée ; 
-  if (branchMatch) { +  * calcul et affichage de la **version candidate** (la prochaine beta) ; 
-    const branchTriplet = branchMatch.slice(1).map(Number); +  * reconstruction de ''logeas-lib'' depuis son dernier commit et réinstallation dans ''logeas-web'' ; 
-    if (compareTriplets(branchTriplet, current) > 0) { +  * démarrage des serveurs locaux (confirmation UAC) ; 
-      target = branchTriplet; // rattrapage : nouveau cycle, jamais utilisé +  * tests unitaires des deux dépôts, puis tests d'interface (Playwright) ; 
-    } +  * génération du rapport qualité et de son analyse ; 
-  } +  * dépôt du rapport, en brouillon, sur le serveur Nono.
-  const isNewCycle = compareTriplets(target, current) > 0;+
  
-  if (mode === 'beta') { +Le rapport est nommé ''run-<version>-<AAAAMMJJ-HHMM>.html'' et porte la clé du code testé (commits des deux dépôts, empreinte des paquets ''logeas-lib'').
-    return isNewCycle ? `${target.join('.')}.1` : `${current.join('.')}.${w + 1}`; +
-  }+
  
-  // mode === 'release' +Le rapport est ensuite validé, validé avec réserves ou refusé dans la carto (Proc#168, « Validation du rapport qualité »). 
-  if (isNewCycle) { + 
-    return target.join('.'); // jamais publié : on le prend tel quel +==== 5.4 Beta : livrer-beta ==== 
-  } + 
-  if (releaseTagExists(current)) { +Le script ''scripts\livrer-beta.bat'' produit la version destinée à la recette. Il s'arrête au premier échec. 
-    return `${x}.${y}.${z + 1}`; // déjà publié : on avance + 
-  } +Les opérations techniques sont les suivantes : 
-  return current.join('.'); // reprend le X.Y.Z déjà utilisé par les betas du cycle + 
-}+  - **porte beta** (''scripts/porte-livraison.js beta'') : les deux dépôts sont propres, à jour et poussés, et un rapport de qualification de la version candidate, validé, porte exactement le dernier commit des deux dépôts et les mêmes paquets ''logeas-lib'' ; 
 +  - mise à jour du numéro de version, 4ᵉ chiffre (''npm run prebuild:beta'', qui exécute ''scripts/version.js beta'') ; 
 +  - génération du rapport de release (''scripts/release-report.js beta --qualification'') : les tests unitaires et le résumé des tests d'interface y sont **repris** de la qualification, rien n'est rejoué ; 
 +  - compilation : ''ng build --configuration production,beta'', vers ''D:\Developpements\VersionPublic\LogeasWeb-Test\'' ; 
 +  - commit dédié « Preparation version X.Y.Z.W », tag annoté ''X.Y.Z.W_beta'' et, si besoin, tag ''web-X.Y.Z.W_beta'' dans ''logeas-lib'' ; 
 +  - après confirmation : publication du commit et du tag, **inscription de la beta dans la trace du rapport qualité** (indispensable à la porte release), reprise du rapport de release dans la carto. 
 + 
 +Si le rapport de release ou le build échoue, la mise à jour du numéro de version est annulée : rien n'est commité ni tagué. 
 + 
 +La beta ne vaut pas validation fonctionnelle : elle fournit l'artefact et les éléments de traçabilité destinés à la recette. 
 + 
 +==== 5.5 Release client : livrer-release ==== 
 + 
 +Le script ''scripts\livrer-release.bat'' produit la version destinée aux utilisateurs. Son déroulé est le même que celui de la beta, derrière la porte release. 
 + 
 +  - **porte release** (''scripts/porte-livraison.js release'') : le tag de la beta est le dernier commit de ''logeas-web'' (**aucun commit depuis la beta**), ''logeas-lib'' est toujours au commit qualifié, le rapport qualité est toujours validé et la **recette de cette beta est « Conforme »** ; 
 +  - mise à jour du numéro de version à 3 chiffres (''npm run prebuild'', qui exécute ''scripts/version.js release'') ; 
 +  - génération du rapport de release ; 
 +  - compilation : ''ng build --configuration production'', vers ''D:\Developpements\VersionPublic\LogeasWeb\'' ; 
 +  - commit dédié, tag annoté ''X.Y.Z_release'' ; 
 +  - après confirmation : publication, inscription de la release dans la trace du rapport qualité. 
 + 
 +Le rapport qualité, publié lors de sa validation, est la pièce qualité de la release. 
 + 
 +**Tout correctif après une beta impose une nouvelle qualification et une nouvelle beta** (Proc#168, cas 3) : aucune modification n'est admise entre la beta recettée et la release. 
 + 
 +==== 5.6 Build hors chaîne ==== 
 + 
 +Les commandes ''npm run build:beta'' et ''npm run build'' restent utilisables, mais elles produisent une version **hors chaîne**, affichée « Version non qualifiée » dans « À propos > Logiciel » et dans son rapport de release. Elles ne doivent pas être utilisées pour une livraison normale ; leur usage en urgence est décrit dans Proc#168, cas 8. 
 + 
 +===== 6. Gestion des versions ===== 
 + 
 +==== 6.1 Format ==== 
 + 
 +Les versions de LoGeAs Web utilisent trois ou quatre composantes numériques : 
 + 
 +  * ''X.Y.Z'' pour une release ; 
 +  * ''X.Y.Z.W'' pour une beta. 
 + 
 +Le suffixe du tag identifie la nature de la publication : 
 + 
 +  * ''_beta'' pour une version de test ; 
 +  * ''_release'' pour une version destinée aux utilisateurs. 
 + 
 +Les règles générales de numérotation sont définies dans la [[certif:procedure:develop:gestionversion|procédure de gestion des versions]]. 
 + 
 +==== 6.2 Calcul automatique ==== 
 + 
 +Le calcul est centralisé dans : 
 + 
 +<code> 
 +scripts/version.js
 </code> </code>
  
-^ Script npm ^ Commande exécutée ^ Mode ^ +La fonction ''resolveNextVersion'' détermine le numéro à utiliser en fonction : 
-| ''npm run build:beta'' | ''node scripts/version.js beta'' puis ''ng build --configuration production,beta'' | beta | + 
-| ''npm run build'' | ''node scripts/version.js release'' puis ''ng build --configuration production'' | release |+  * de la version actuelle de ''package.json'' ; 
 +  * du nom de la branche de version ; 
 +  * du mode de génération (beta ou release) ; 
 +  * des tags de release déjà présents dans Git. 
 + 
 +Pour une beta, le quatrième chiffre est incrémenté à chaque nouvelle génération du même cycle. 
 + 
 +Lorsqu'une nouvelle branche numérotée correspond à un cycle ultérieur, le script utilise son numéro comme nouvelle base de version. 
 + 
 +Pour une release, le quatrième chiffre est supprimé. Le numéro ''X.Y.Z'' utilisé par les betas est repris s'il n'a pas déjà été publié. Si une release portant ce numéro existe déjà, le script avance vers un nouveau numéro conformément à la règle implémentée. 
 + 
 +La commande ''node scripts/version.js beta --simuler'' affiche la version candidate sans rien modifier. 
 + 
 +==== 6.3 Traçabilité de la version ====
  
-==== 4.3 Exemple déroulé sur un cycle complet ====+Le fichier ''src/assets/version.ts'' est régénéré lors de la préparation d'un build.
  
-Point de départ : la dernière release livrée est ''11.0.23'' (tag ''11.0.23_release'' déjà existant). La branche de version du cycle suivant, ''11.0.25'', existe déjà et contient du travail non encore livré — ''package.json'' est donc en retard de 2 par rapport au nom de la branche.+Il contient notamment les informations permettant d'identifier :
  
-{{ :certif:procedure:develop:proceduremiseenligne:numerotation-frise.svg | Frise d'exemple : évolution du numéro de version sur un cycle complet}} +  * la branche Git ; 
-NB : SVG stocké sur le wiki éditable par exemple avec Inkscape+  * le commit source ; 
 +  * la date de génération.
  
-(fichier source : ''numerotation-frise.svg'', à téléverser dans le gestionnaire de médias du wiki avant que l'image ne s'affiche)+Ces données permettent de rapprocher une version exécutée de son état source.
  
-^ Étape ^ Procédure ^ Branche ^ package.json (avant → après) ^ Tag posé ^ +==== 6.4 Cas particuliers ====
-| 1 | Travail perso (manuel, plusieurs commits) | feature/import-csv | 11.0.23 → 11.0.23 (inchangé) | — | +
-| 2 | fusion-dev (1ère vérification build/tests/lint, log complet) | 11.0.25 | 11.0.23 → 11.0.23 (inchangé) | — | +
-| 3 | release-beta (1ère beta) | 11.0.25 | 11.0.23 → 11.0.25.1 (rattrapage sur la branche, W démarre à 1) | 11.0.25.1_beta | +
-| 4 | Travail perso + fusion-dev (correctif suite retour de test) | 11.0.25 | 11.0.25.1 → 11.0.25.1 (inchangé) | — | +
-| 5 | release-beta (2ᵉ beta) | 11.0.25 | 11.0.25.1 → 11.0.25.2 (W incrémenté, X.Y.Z inchangé) | 11.0.25.2_beta | +
-| 6 | release-client | 11.0.25 | 11.0.25.2 → 11.0.25 (W retiré, même X.Y.Z que les betas — jamais publié avant) | 11.0.25_release | +
-| 7 | release-beta (cycle suivant, branche 11.0.26) | 11.0.26 | 11.0.25 → 11.0.26.1 (rattrapage sur la nouvelle branche) | 11.0.26.1_beta |+
  
-**Lecture :** l'étape 1 (travail perso) ne fait l'objet d'aucune vérification technique — c'est l'étape 2 (fusion-dev) qui vérifie build/tests/lint pour la première fois. Le numéro de version ne bouge qu'aux étapes de génération (release-beta, release-client). Les betas successives d'un même cycle (étapes 3 et 5) ne font varier que le 4ᵉ chiffre. La release finale (étape 6) reprend exactement le X.Y.Z des betas qui l'ont précédée puisqu'il n'avait jamais été publié — aucun numéro n'est « sauté » ou laissé inutilisé. Le cycle suivant (étape 7) reprend logiquement le tout prochain numéro (11.0.26, pas 11.0.27 ou plus) : une fois la dérive historique corrigée (voir 1.1), la convention veut que le nom d'une nouvelle branche de version reprenne toujours le numéro immédiatement suivant la dernière release publiée, pour ne plus jamais laisser de trou dans la séquence des numéros livrés aux utilisateurs. Si une release devait à l'inverse être regénérée sur ''11.0.25'' sans nouvelle beta (le tag ''11.0.25_release'' existant déjà), ce même numéro ''11.0.26'' serait alors utilisé pour cette relivraison plutôt que pour un nouveau cycle — les deux cas sont exclusifs l'un de l'autre.+Les cas de changement de version mineure, de correction d'une version déjà livrée et de travail parallèle sur plusieurs versions sont décrits dans Proc#168 (cas 6 et 7) et dans le [[certif:procedure:develop:gestionversionpratique|guide pratique]].
  
-----+Ils ne doivent pas conduire à réécrire l'historique d'une version déjà publiée.
  
-===== 5. Garde-fous et traçabilité (aspects qualité) =====+===== 7. Contrôles et garde-fous =====
  
-Ces garde-fous s'appliquent uniformément aux 3 procédures outillées (fusion-dev, release-beta, release-client) :+Les procédures outillées appliquent des contrôles destinés à éviter les publications incohérentes ou non traçables.
  
-  * **Aucune action destructive automatique** : jamais de ''push --force'', jamais de suppression de branche ou de tag. En cas de problème (conflit ambigu, échec de test, divergence avec le serveur distant), la procédure s'arrête et signale l'anomalie plutôt que de forcer une résolution automatique. +^ Contrôle ^ Étape concernée ^ Objectif ^ 
-  * **Blocage systématique sur échec** : un build cassé ou des tests en échec bloquent la suite de la procédure — impossible de produire une beta ou une release sur du code non fonctionnel. Un échec préexistant et sans rapport avec le changement en cours est explicitement signalé plutôt que masqué ou corrigé silencieusement. +| État des dépôts (propres, à jour, poussés) | Intégration, qualification, beta, release | Éviter de publier à partir d'un état local non maîtrisé | 
-  * **Traçabilité du code livré** : ''src/assets/version.ts'', régénéré à chaque build, embarque la branche Git, le hash de commit court et la date de build — chaque livraison (beta ou release) est ainsi reliée sans ambiguïté à un état précis du code source. +| Branche de version | Toutes les étapes outillées | Garantir que l'opération concerne la branche attendue | 
-  * **Traçabilité des fusions** : depuis la mise à jour de fusion-dev, chaque commit de fusion porte en corps de message la liste complète des commits individuels intégrés, et non plus seulement un titre générique. +| Compilation, tests unitaires, lint | Intégration | Détecter les erreurs avant l'intégration | 
-  * **Traçabilité des publications** : chaque beta et chaque release est marquée par un tag Git annoté et poussé, permettant de retrouver exactement quel commit correspond à quelle publication. +| Tests unitaires et tests d'interface | Qualification | Produire le rapport qualité de la version candidate | 
-  * **Discipline de numérotation** : voir section 4 — aucun numéro de version publié ne peut être réutilisé (vérification par consultation des tags existants), et aucun numéro n'est utilisé par une beta sans finir par être publié en release.+| Porte beta | Beta | N'ouvrir une beta que sur un code qualifié, avec un rapport validé | 
 +| Porte release | Release | N'ouvrir une release que sur la beta recettée conforme, sans commit depuis | 
 +| Paquets ''logeas-lib'' installés | Beta, release | Garantir que la bibliothèque livrée est celle qui a été qualifiée | 
 +| Numéro de version et tags | Beta, release | Éviter les collisions et préserver la traçabilité | 
 +| Séparation des répertoires de sortie | Beta, release | Empêcher la confusion entre test et production | 
 +| Liste des commits intégrés | Intégration | Conserver la traçabilité des changements | 
 +| Rapport de release | Beta, release | Documenter les changements et renvoyer au rapport qualité |
  
-----+En cas d'échec d'un contrôle bloquant, la procédure s'arrête et signale l'anomalie. **Une porte ne se contourne jamais** : si le blocage est injustifié, c'est un défaut des scripts, à signaler et corriger.
  
-===== 6. Ce qui reste volontairement manuel =====+Aucune procédure ne doit résoudre silencieusement un conflit métier ou écraser des modifications non validées.
  
-  * **Le déploiement final vers les serveurs** (test et client) : ''LogeasWeb'' et ''LogeasWeb-Test'' sont des dossiers intermédiaires locaux, copiés à la main vers le serveur réel. Ces serveurs ne sont accessibles que par connexion à distance (bureau à distance), sans accès réseau direct depuis le poste de développement — la copie ne peut donc pas être automatisée dans le cadre de ce dispositif. +Les opérations de publication n'utilisent pas ''push --force'' et ne suppriment pas automatiquement des branches ou des tags.
-  * **La sauvegarde du travail personnel** (étape 1) : choix délibéré pour ne pas ralentir les sauvegardes fréquentes d'un travail potentiellement inachevé (voir 3.1). +
-  * **La décision de progression** : quand fusionner, quand passer en beta, quand livrer au client — ce sont des décisions d'équipe, jamais automatiques. Les procédures exécutent les vérifications techniques une fois la décision prise.+
  
-----+Les échecs de tests déjà connus doivent être identifiés et distingués des régressions introduites par le changement en cours : c'est l'objet de la décision « Validé avec réserves » (Proc#168).
  
-===== 7. Évolutions apportées par ce dispositif =====+===== 8. Rapports et éléments de preuve =====
  
-^ Avant ^ Après ^ +Les éléments suivants permettent de reconstituer une publication :
-| Étapes manuelles, non reproductibles | 3 procédures outillées (fusion-dev, release-beta, release-client), identiques à chaque exécution | +
-| Aucun garde-fou : possibilité de tagger un build cassé | Blocage systématique si le build échoue ou si des tests échouent | +
-| ''package.json'' dérivé du nom des branches (23 vs 25) sans détection | Rattrapage automatique sur le nom de la branche de version | +
-| Build de test et build client indifférenciés (tout partait vers ''LogeasWeb'') | Configuration Angular ''beta'' dédiée, sortie routée vers ''LogeasWeb-Test'' | +
-| Numéro de beta et de release parfois désynchronisés du nom de branche, betas consommant un numéro jamais publié | Beta = 4ᵉ chiffre, release = reprise du même 3ᵉ chiffre — aucun numéro orphelin | +
-| Coquille orthographique reproduite sur les tags (''realease'') | Orthographe correcte (''release'') sur les nouveaux tags ; anciens tags non renommés | +
-| Commit de fusion au titre générique, sans détail | Commit de fusion enrichi du log complet des commits intégrés |+
  
-----+  * l'historique Git de la branche concernée ; 
 +  * le commit de fusion et la liste des commits intégrés ; 
 +  * le commit « Preparation version » ; 
 +  * le tag annoté de beta ou de release (et le tag ''web-*'' de ''logeas-lib'') ; 
 +  * les informations intégrées dans ''version.ts'' ; 
 +  * le **rapport qualité** de la version (''run-<version>-<date>.html''), sa décision de validation et la recette de la beta ; 
 +  * le **rapport de release** HTML, enregistré dans ''src/assets/releases/'' et référencé dans ''manifest.json''.
  
-===== 8. Annexes techniques =====+^ Élément ^ Où le consulter ^ 
 +| Rapports qualité, décisions, recettes, rapports de release | carto, écran « Rapports de version » ([[https://cartographie-fonctionnelle.logeas-web.fr/RapportsVersion]]) | 
 +| Historique d'un rapport (validation, publication, beta, recette, release) | table ''ApprobDoc'' du serveur Nono, trace du rapport | 
 +| Qualification d'une version livrée | son rapport de release et « À propos > Logiciel » |
  
-==== 8.1 Fichiers concernés (dépôt logeas-web) ====+Les modalités de validation et de conservation de ces preuves relèvent de la [[certif:procedure:develop:chainequalificationlivraison|chaîne de qualification et de livraison]].
  
-^ Fichier ^ Rôle ^ +===== 9. Opérations restant manuelles =====
-| ''scripts/version.js'' | Calcul et application de la règle de numérotation (section 4) | +
-| ''angular.json'' (configuration ''beta'' du builder ''build'') | Redirection de la sortie de build vers ''LogeasWeb-Test'' en mode beta | +
-| ''package.json'' (scripts ''build'', ''build:beta'', ''prebuild'', ''prebuild:beta'') | Points d'entrée des générations beta et release |+
  
-==== 8.2 Procédures outillées (assistant Claude Code) ====+Les opérations suivantes restent sous la responsabilité des personnes habilitées :
  
-^ Commande ^ Fichier source ^ Rôle ^ +  * le choix du moment de l'intégration ; 
-| ''/fusion-dev'' | ''.claude/commands/fusion-dev.md'' | Étape 2 : intégration + vérification + log complet | +  * le lancement de la qualification ; 
-| ''/release-beta'' | ''.claude/commands/release-beta.md'' | Étape 3 : build beta + tag | +  * la relecture et la validation du rapport qualité ; 
-| ''/release-client'' | ''.claude/commands/release-client.md'' | Étape 4 : build release + tag |+  * le lancement de la beta ; 
 +  * la recette de la beta ; 
 +  * le lancement de la release ; 
 +  * le transfert des fichiers générés vers les serveurs ; 
 +  * la vérification du déploiement sur l'environnement cible.
  
-==== 8.3 Convention de nommage des tags Git ====+La séparation entre génération, validation et déploiement permet de conserver un contrôle humain sur les étapes engageant la mise à disposition du logiciel.
  
-  * Beta : ''X.Y.Z.W_beta'' (ex. ''11.0.25.1_beta'') +===== 10. Maintenance du dispositif =====
-  * Release : ''X.Y.Z_release'' (ex. ''11.0.25_release'')+
  
-----+Les scripts et configurations qui mettent en œuvre le cycle de release font partie du dispositif de développement de LoGeAs Web.
  
-===== 9. Points ouverts à valider avec l'équipe =====+Toute modification significative de ces éléments doit être contrôlée et testée avant d'être utilisée pour une publication.
  
-  * Le passage en beta n'est pour l'instant jamais sauté avant une release client de façon automatique — à confirmer que c'est bien la règle voulue dans tous les cas. +Les évolutions du dispositif doivent préserver :
-  * La convention de nommage des branches de version (ex. ''11.0.25'') suppose de connaître le numéro cible à l'avance — à confirmer que c'est toujours décidé en amont et non ajusté en cours de cycle. +
-  * Les noms des procédures pourront être ajustés une fois éprouvés en pratique, avant validation définitive de cette page pour le dossier de certification.+
  
-----+  * la traçabilité des versions ; 
 +  * la reproductibilité des générations ; 
 +  * la séparation des environnements ; 
 +  * la fiabilité des contrôles et des portes ; 
 +  * la conservation des preuves nécessaires à la certification.
  
-//Document généré à partir de l'état du dépôt ''logeas-web'' au 2026-08-03. À revalider après toute évolution du dispositif décrit ci-dessus.//+La présente procédure doit être révisée lorsque le fonctionnement effectif du cycle de release évolue.