# Cible produit/UI du Devtools

> Archive historique conservée côté `TTM_API`.
>
> Source de vérité active : `C:\Users\VT\PhpstormProjects\ttm-dev-tools\docs\DEV_TOOLS_DEPLOYMENT_AUDIT.md` et `C:\Users\VT\PhpstormProjects\ttm-dev-tools\docs\README_DEV_TOOLS_UI.md`.
>
> Ce document reflète un cadrage antérieur à l’extraction du `dev-tools` vers `ttm-dev-tools`. À utiliser seulement comme contexte d’archive.

_Date : 2026-04-06_

## Position du document

Ce document n’est pas un audit.
Ce n’est pas non plus une synthèse molle de constats UX.

C’est une **proposition cible produit/UI** pour transformer le Devtools en outil de promotion de release réellement utilisable au quotidien.

Le point de départ n’est pas la structure technique actuelle du code ni la liste des actions CLI disponibles. Le point de départ est le **processus réel de promotion de release** tel qu’il est pratiqué :

1. mon dev local fonctionne ;
2. je build mes sources ;
3. je crée une release locale figée ;
4. je teste cette release localement ;
5. je pousse cette release à distance sans l’activer ;
6. je teste la release distante ;
7. je prépare une base de données compatible ;
8. je migre le schéma et les données si nécessaire ;
9. j’expose la release sur un domaine / vhost / preview dédié ;
10. je teste dans des conditions réelles ;
11. si tout est bon, j’active la release ;
12. si nécessaire, je rollback simplement.

La cible produit/UI doit donc être simple à lire :
- **la release est le centre** ;
- **le Devtools raconte un parcours** ;
- **chaque page répond à un moment précis de ce parcours** ;
- **l’outil aide à décider le prochain pas sûr** ;
- **les détails techniques restent disponibles, mais ne dirigent plus l’expérience**.

---

## 1. Principe directeur

Le Devtools ne doit plus être perçu comme une collection de pages techniques côte à côte.
Il doit être perçu comme un **cockpit de promotion de release**.

La différence est structurante.

Aujourd’hui, la logique dominante est encore :
- une page pour build ;
- une page pour deploy ;
- une page pour les releases ;
- une page pour la DB ;
- une page pour le runtime ;
- une page pour les profils.

Cette organisation par capacités techniques est utile pour l’implémentation interne, mais elle n’est pas le bon modèle mental pour l’usage réel. En pratique, l’utilisateur n’essaie pas de “faire du runtime” ou “faire de la DB”. Il essaie de **faire avancer un release** vers un état prêt à être activé.

Le Devtools cible doit donc toujours répondre, partout, à quatre questions :

1. **Sur quoi j’agis ?**
   - quelle release ;
   - quelle cible ;
   - quelle base ;
   - quel profil actif.

2. **Où j’en suis ?**
   - release seulement buildée ;
   - test local validé ou non ;
   - push distant fait ou non ;
   - base prête ou non ;
   - preview prête ou non ;
   - activation possible ou non.

3. **Quel est le prochain pas sûr ?**
   - le prochain pas normal doit toujours être explicite ;
   - l’utilisateur ne doit pas devoir reconstituer l’ordre mentalement.

4. **Qu’est-ce qui me bloque ?**
   - blocage release ;
   - blocage DB ;
   - blocage runtime ;
   - blocage fraîcheur / incohérence de contexte.

Décision produit/UI :
**le Devtools devient d’abord un parcours de promotion de release, et seulement ensuite une console de détail technique.**

---

## 2. Modèle mental cible

Le modèle mental cible doit être explicite, stable et unique.

### 2.1 La release est l’unité centrale
L’unité principale du Devtools n’est ni le serveur, ni le profil, ni la page courante.
L’unité principale est **la release**.

Cela implique :
- on choisit d’abord une release ;
- on lit ensuite où elle en est ;
- on voit ensuite ce qu’on peut faire avec elle ;
- toutes les pages sont des vues différentes du même objet.

Décision :
**aucune page ne doit donner l’impression qu’elle travaille indépendamment du release sélectionné.**

### 2.2 Les pages techniques deviennent des vues d’un même parcours
Les pages restent utiles, mais elles ne doivent plus être vécues comme des silos.

Leur rôle cible :
- `Build` = fabriquer la release ;
- `Déploiement` = pousser la release ;
- `Runtime` = vérifier qu’elle tourne ;
- `Base de données` = sécuriser et rendre compatible la DB cible ;
- `Releases` = basculer ou revenir en arrière ;
- `Profils / Env` = choisir et comprendre la cible.

Décision :
**chaque page doit être une étape ou un zoom du même parcours de promotion.**

### 2.3 Il faut distinguer trois vérités
Le Devtools doit afficher trois types de vérité sans les mélanger.

#### A. Vérité de contexte
Répond à :
- quelle release est sélectionnée ;
- quelle cible est active ;
- quel profil est utilisé ;
- quelle DB est concernée.

Cette vérité doit être **globale** et stable.

#### B. Vérité système
Répond à :
- ce que le système observe réellement maintenant ;
- release présente ou absente côté distant ;
- runtime joignable ou non ;
- DB lisible ou non ;
- socket connecté ou en fallback.

Cette vérité doit être **fraîche, horodatée et non contradictoire**.

#### C. Vérité de progression du pipeline
Répond à :
- le build est-il prêt ;
- le test local est-il fait ;
- le push distant est-il fait ;
- la DB est-elle prête ;
- l’activation est-elle possible.

Cette vérité doit être **orientée décision**, pas purement technique.

Décision :
**le Devtools doit toujours afficher ces trois vérités distinctement.**
Il ne doit jamais demander à l’utilisateur de déduire la progression à partir de détails système bruts.

### 2.4 Ce que l’utilisateur doit comprendre sans effort
À tout moment, sans cliquer dans les détails, l’utilisateur doit comprendre :
- quelle release il manipule ;
- quelle release est active côté distant ;
- quelle cible est concernée ;
- si l’état affiché est frais ou potentiellement obsolète ;
- si la release est prête pour l’étape suivante ;
- quel est le prochain pas normal ;
- quelle action est bloquée et pourquoi.

Décision :
**si une information est indispensable pour décider, elle ne doit pas vivre dans un panneau secondaire.**

---

## 3. Structure cible du Devtools

La structure cible la plus simple n’est pas de supprimer toutes les pages.
La bonne décision est de **garder les pages spécialisées**, mais de les remettre sous une structure transversale unique.

### 3.1 Décision structurante
Le Devtools doit avoir deux niveaux de lecture :

1. **un niveau transverse “Promotion de release”** ;
2. **des pages spécialisées par étape**.

Autrement dit :
- on garde des pages ;
- mais elles ne sont plus autonomes mentalement ;
- elles sont reliées par un contexte global et une progression commune.

### 3.2 Faut-il garder les pages actuelles ?
Oui, mais pas toutes sous la même signification.

#### Pages à garder
- `Build`
- `Déploiement`
- `Runtime`
- `Base de données`
- `Releases`
- `Profils`

#### Pages à repositionner
- `Profils` doit être repositionnée comme **`Env`** dans le récit produit ;
- `Releases` ne doit plus être lue comme une page “liste d’outils de release”, mais comme la **page de bascule finale et de retour arrière** ;
- `Runtime` doit être repositionnée comme **page de validation opérationnelle**, pas comme cockpit de debug principal.

### 3.3 Renommages recommandés
Décision tranchée :

- `Build` → garder `Build`
- `Déploiement` → garder `Déploiement`
- `Runtime` → garder `Runtime`
- `Base de données` → garder `Base de données`
- `Releases` → garder `Releases`, mais avec sous-titre produit très clair : `Activation et rollback`
- `Profils` → **renommer visuellement en `Env`** avec sous-titre `Cible et configuration`

Pourquoi ce choix :
- `Env` est plus proche du modèle d’usage réel ;
- `Profils` est vrai techniquement mais trop interne ;
- conserver le terme dans la technique reste possible, mais l’UI doit afficher d’abord l’intention produit.

### 3.4 Faut-il regrouper certaines responsabilités ?
Oui, mais seulement au niveau du récit UI, pas forcément au niveau backend.

#### Ce qu’il faut regrouper conceptuellement
- `Déploiement` + `Runtime` + `Releases` participent au même sous-parcours :
  - pousser ;
  - valider ;
  - activer.

- `Env` + `Base de données` fournissent le contexte critique de la promotion :
  - cible ;
  - DB ;
  - URLs ;
  - profil.

#### Ce qu’il ne faut pas fusionner en une seule page
- il ne faut pas fusionner `Déploiement`, `Runtime` et `Releases` en une page monolithe ;
- il ne faut pas absorber `Base de données` dans `Déploiement` ;
- il ne faut pas faire de `Runtime` un panneau secondaire permanent si cela masque le contrôle réel.

Décision :
**on ne fusionne pas techniquement les pages ; on les aligne produit/UI autour d’un pipeline commun.**

### 3.5 Faut-il introduire une vue transversale “promotion de release” ?
Oui. C’est la décision la plus importante.

Le Devtools doit introduire une vue transverse de type :
- soit une vraie page `Promotion` / `Pipeline` ;
- soit un bloc sticky global très présent sur les pages clés.

Choix recommandé :
**introduire une vue transverse de progression visible sur toutes les pages clés**, plutôt qu’une nouvelle page autonome qui deviendrait encore un écran de plus.

### 3.6 Structure cible argumentée
Structure recommandée :

1. **Bandeau global obligatoire**
   - visible partout ;
   - répond à `sur quoi j’agis ?`.

2. **Vue pipeline transverse**
   - visible partout sur les pages du parcours ;
   - répond à `où j’en suis ?`.

3. **Pages spécialisées**
   - `Build`
   - `Déploiement`
   - `Runtime`
   - `Base de données`
   - `Releases`
   - `Env`

4. **Bloc “Prochain pas sûr”**
   - visible en bas de chaque page principale ;
   - répond à `que dois-je faire maintenant ?`.

Décision finale :
**la meilleure structure n’est pas “moins de pages”, c’est “plus de cohérence transverse”.**

---

## 4. Bandeau global obligatoire

Le bandeau global doit être affiché sur toutes les pages, sans exception.
C’est la source de vérité de contexte.

### 4.1 Informations obligatoires
Le bandeau doit afficher exactement, dans cet ordre :

1. **Release sélectionnée**
2. **Release active distante**
3. **Environnement / cible**
4. **Profil actif**
5. **Base cible**
6. **Fraîcheur de l’état**
7. **État temps réel / reconnexion**
8. **Blocage critique éventuel**

### 4.2 Ce qui doit être le plus visible
Les éléments les plus visibles doivent être :
- la release sélectionnée ;
- la release active distante ;
- l’environnement / cible ;
- le blocage critique s’il existe.

Pourquoi :
ce sont eux qui changent immédiatement le sens d’une action.

### 4.3 Ce qui doit être moins visible
Doivent être présents mais moins dominants :
- profil actif ;
- fraîcheur de l’état ;
- état temps réel / reconnexion.

Pourquoi :
ils sont essentiels à la confiance, mais moins structurants que le triplet `release / release active / cible`.

### 4.4 Forme recommandée

#### Ligne 1 — contexte critique
- `Release visée : 20260404-014000`
- `Active distante : 20260403-231500`
- `Cible : Préprod`
- `Blocage : release absente côté distant` si applicable

#### Ligne 2 — contexte de support
- `Profil : default`
- `DB cible : ttm_api / stackmod-dev-mariadb`
- `État : vérifié il y a 18 s`
- `Temps réel : connecté` ou `Reconnexion…`

### 4.5 Comportement visuel en cas d’incohérence

#### Cas A — release sélectionnée absente côté distant
- `Blocage` passe en rouge critique ;
- `Active distante` reste visible pour comparaison ;
- `Activer` est désactivé ;
- le pipeline transverse marque `Activation` comme bloquée.

#### Cas B — contexte possiblement obsolète
- badge ambre `Données à rafraîchir` ;
- les actions non destructives restent possibles ;
- les actions sensibles peuvent rester gelées si l’obsolescence touche la cible.

#### Cas C — profil actif incohérent avec le runtime observé
- afficher `Contexte contradictoire détecté` en critique ;
- geler les actions sensibles ;
- CTA visible : `Rafraîchir le contexte`.

### 4.6 Ce qui doit être bloquant
Doit être bloquant dans le bandeau :
- release sélectionnée incohérente ;
- cible inconnue ;
- DB cible inconnue pour une action DB ;
- contradiction de profil / runtime ;
- diagnostic critique non levé pour action sensible.

### 4.7 Ce qui doit être seulement informatif
Doit rester informatif :
- socket en reconnexion si le dernier état utile reste fiable ;
- donnée pas totalement fraîche mais non critique ;
- latence de rafraîchissement ;
- détails de couche versionnée / locale si pas de risque immédiat.

Décision :
**le bandeau global doit être le premier contrôle de sécurité cognitive de l’outil.**

---

## 5. Vue pipeline / progression

Le Devtools doit afficher une vue transverse de progression presque partout.

### 5.1 Pipeline recommandé
Le pipeline cible à afficher est :

1. **Build**
2. **Test local**
3. **Push distant**
4. **Validation distante**
5. **Base**
6. **Preview**
7. **Activation**

Pourquoi cette forme :
- elle reflète le parcours réel ;
- elle reste assez courte ;
- elle évite de dupliquer des micro-étapes trop techniques ;
- elle place `Base` et `Preview` au bon niveau de décision.

### 5.2 Statuts possibles de chaque étape
Chaque étape du pipeline doit avoir exactement ces statuts :
- `Non commencé`
- `En cours`
- `Prêt`
- `Bloqué`
- `Obsolète`
- `Non requis`

### 5.3 Signification des statuts
- **Non commencé** : aucune preuve exploitable de réalisation ;
- **En cours** : action ou vérification en train de se faire ;
- **Prêt** : l’étape est validée pour la release sélectionnée et la cible courante ;
- **Bloqué** : il manque une condition nécessaire ;
- **Obsolète** : l’étape avait été valide, mais le contexte a changé ;
- **Non requis** : étape non nécessaire dans le contexte courant.

### 5.4 Comment afficher ce qui est prêt / en attente / bloqué / obsolète

#### Prêt
- badge vert ;
- court résumé de preuve : `build effectué`, `runtime vérifié`, `backup disponible`, etc.

#### En attente / non commencé
- badge neutre ;
- pas de rouge ;
- microcopie courte : `à faire`.

#### Bloqué
- badge rouge ;
- cause courte affichée immédiatement ;
- clic possible vers la page qui permet de lever le blocage.

#### Obsolète
- badge ambre ;
- mention explicite du changement de contexte :
  - release changée ;
  - cible changée ;
  - profil changé ;
  - donnée plus fraîche nécessaire.

### 5.5 Où afficher cette vue
Choix recommandé :
- **visible partout** sur les pages du parcours principal ;
- **sticky sous le bandeau global** sur desktop ;
- **compacte et scrollable** sur mobile ou petit écran.

### 5.6 Faut-il l’afficher sur toutes les pages ?
Oui, sauf éventuellement sur les écrans très secondaires d’édition experte.

Décision :
- afficher la vue pipeline sur `Build`, `Déploiement`, `Runtime`, `Base de données`, `Releases`, `Env` ;
- si nécessaire, version plus compacte sur `Env`.

### 5.7 Ce que cette vue doit apporter
Cette vue ne doit pas être décorative.
Elle doit permettre de voir immédiatement :
- ce qui est déjà bon ;
- ce qui manque ;
- ce qui bloque ;
- où aller ensuite.

Décision :
**la vue pipeline est la colonne vertébrale de l’expérience, pas un résumé secondaire.**

---

## 6. Refonte cible page par page

### 6.1 Build

#### Rôle cible de la page
Fabriquer la release sélectionnée et établir une preuve simple qu’elle est prête à être testée ou poussée.

#### Priorité d’affichage
1. release sélectionnée ;
2. projets ciblés ;
3. actions de build ;
4. dernier résultat ;
5. preuve `release prête localement`.

#### Secondaire
- snapshots détaillés ;
- chemins complets ;
- détails techniques de manifeste ;
- build distant API.

#### Ce qui doit être retiré ou déplacé
- tout message contradictoire avec l’état réel ;
- tout rappel global déjà porté par le bandeau ;
- toute pédagogie trop longue.

#### Boutons principaux
- `Build complet`
- `Build shared`
- `Build API`
- `Build front`

#### Boutons secondaires
- `Utiliser dernier local`
- `Utiliser current distant`
- `Build API distant` si nécessaire, mais replié en secondaire.

#### Prochain pas à afficher
- `Tester localement cette release`
- si la release est prête : `Pousser cette release à distance`

#### Blocages qui doivent désactiver l’action
- release non renseignée ;
- contexte contradictoire ;
- build déjà en cours ;
- prérequis manquant pour build distant.

#### Décision produit/UI
**Build doit être une page de fabrication, pas une page de contexte technique.**

### 6.2 Déploiement

#### Rôle cible de la page
Pousser une release déjà prête vers la cible sélectionnée, sans l’activer.

#### Priorité d’affichage
1. release sélectionnée ;
2. cible ;
3. action principale `Envoyer la release` ;
4. résultat ;
5. renvoi vers validation distante.

#### Secondaire
- dry-run détaillé ;
- actions avancées isolées ;
- détails CLI bruts ;
- détails profil.

#### Ce qui doit être retiré ou déplacé
- tout ce qui ressemble à une logique DB ;
- tout ce qui ressemble à une logique Runtime de second niveau ;
- tout bloc trop riche qui détourne de l’action principale.

#### Boutons principaux
- `Vérifier avant envoi`
- `Envoyer la release`
- `Envoyer + finaliser`

#### Boutons secondaires
- `Sync seul`
- `Finaliser seul`
- `Voir le détail technique`

#### Prochain pas à afficher
- `Valider la release distante`
- si la DB est concernée : `Préparer la base avant activation`

#### Blocages qui doivent désactiver l’action
- release locale non prête ;
- cible non confirmée ;
- dry-run bloquant ;
- contradiction de contexte.

#### Décision produit/UI
**Déploiement doit raconter “j’envoie”, pas “je gère des outils de déploiement”.**

### 6.3 Releases

#### Rôle cible de la page
Décider de la bascule finale : activer le release validé ou revenir au précédent.

#### Priorité d’affichage
1. release sélectionnée ;
2. release active distante ;
3. verdict `prêt à activer ?` ;
4. actions `Activer` / `Rollback` ;
5. résultat de bascule.

#### Secondaire
- cleanup ;
- maintenance ;
- diagnostics de layout détaillés ;
- preview technique.

#### Ce qui doit être retiré ou déplacé
- tout ce qui dilue la comparaison `release visée / active distante` ;
- toute maintenance à faible fréquence visible au même niveau que `Activer`.

#### Boutons principaux
- `Activer ce release`
- `Revenir au release précédent`

#### Boutons secondaires
- `Vérifier la présence du release`
- `Activer + smoke`
- `Nettoyer les anciens releases`

#### Prochain pas à afficher
- après activation : `Surveiller le runtime` ;
- après rollback : `Vérifier la stabilité après retour arrière`.

#### Blocages qui doivent désactiver l’action
- release absente côté distant ;
- diagnostic critique non levé ;
- rollback impossible faute de release précédent.

#### Décision produit/UI
**Releases n’est pas une page de gestion de stock ; c’est la page de décision finale.**

### 6.4 Base de données

#### Rôle cible de la page
Préparer et sécuriser la DB cible pour la release en cours de promotion.

#### Priorité d’affichage
1. DB cible ;
2. release utilisée pour migration ;
3. diagnostic ;
4. backup ;
5. action recommandée ;
6. résultat.

#### Secondaire
- clonage avancé ;
- restauration ;
- setup ;
- détails techniques.

#### Ce qui doit être retiré ou déplacé
- maintenance historique ;
- détails d’artefacts trop tôt ;
- mélange visuel source / cible / release / contexte système.

#### Boutons principaux
- `Tester la connexion`
- `Créer un backup`
- `Migrer le release`

#### Boutons secondaires
- `Préparer une base non-prod`
- `Restaurer une base cible`
- `Mode expert`

#### Prochain pas à afficher
- `Vérifier le runtime distant`
- ou `Activer si la validation globale est verte`.

#### Blocages qui doivent désactiver l’action
- DB cible non confirmée ;
- release de migration inconnue ;
- diagnostic critique ;
- absence d’artefact source pour restauration.

#### Décision produit/UI
**Base de données doit devenir une page de décision contrôlée, pas une page de puissance technique brute.**

### 6.5 Runtime

#### Rôle cible de la page
Valider que la release tourne correctement, localement puis à distance.

#### Priorité d’affichage
1. distinction local / distant ;
2. état des services ;
3. actions normales ;
4. état détaillé ;
5. verdict de validation runtime.

#### Secondaire
- terminal ;
- logs longs ;
- diagnostics avancés ;
- maintenance structurelle.

#### Ce qui doit être retiré ou déplacé
- tout ce qui fait du terminal la lecture principale ;
- tout ce qui ressemble à un panneau d’administration générique.

#### Boutons principaux
- `Vérifier`
- `Démarrer`
- `Arrêter`
- `Redémarrer`

#### Boutons secondaires
- `Ouvrir le terminal`
- `Voir les logs`
- `Diagnostics avancés`

#### Prochain pas à afficher
- `Passer à l’étape suivante du pipeline` ;
- ou `Corriger le blocage runtime détecté`.

#### Blocages qui doivent désactiver l’action
- profil incohérent ;
- cible ambiguë ;
- action déjà en cours sur le même service.

#### Décision produit/UI
**Runtime doit servir à valider le fonctionnement, pas à exposer toute la mécanique de debug au premier plan.**

### 6.6 Profils / Env

#### Rôle cible de la page
Permettre de choisir, comprendre et éditer la cible de promotion.

#### Priorité d’affichage
1. environnement courant ;
2. cible associée ;
3. profil réellement utilisé ;
4. URLs publiques ;
5. couche modifiée.

#### Secondaire
- JSON expert ;
- détails avancés Apache / preview / builder ;
- champs rares.

#### Ce qui doit être retiré ou déplacé
- présentation initiale trop technique ;
- champs avancés visibles avant l’essentiel ;
- confusion entre ce qui est édité et ce qui est chargé.

#### Boutons principaux
- `Ouvrir`
- `Créer`
- `Dupliquer`
- `Enregistrer`
- `Activer cet environnement`

#### Boutons secondaires
- `Mode expert JSON`
- `Voir les couches`

#### Prochain pas à afficher
- `Revenir au pipeline avec cette cible`.

#### Blocages qui doivent désactiver l’action
- changement de profil pendant une action sensible ;
- suppression de surcharge sans confirmation renforcée.

#### Décision produit/UI
**La page doit s’appeler visuellement `Env`, parce que l’utilisateur choisit d’abord une cible, pas un objet technique nommé profil.**

---

## 7. Focus spécial : page Base de données

La page `Base de données` est le point de risque maximal.
C’est donc la page qui doit être la plus simplifiée au premier niveau et la plus sévèrement hiérarchisée.

### 7.1 Principe de refonte
La page doit être organisée en deux niveaux :

1. **Niveau principal simple**
2. **Niveau expert secondaire**

### 7.2 Niveau principal simple
Le niveau principal doit répondre uniquement à ces questions :
- quelle DB cible est concernée ;
- quelle release est en train d’être promue ;
- la DB est-elle prête ;
- faut-il faire un backup ;
- faut-il migrer ;
- quel est le prochain pas.

#### Structure cible du niveau principal
1. **Contexte DB critique**
2. **Diagnostic**
3. **Backup**
4. **Migration**
5. **Résultat récent**
6. **Prochain pas**

### 7.3 Niveau expert secondaire
Le niveau expert contient :
- clonage ;
- restauration ;
- artefacts d’export ;
- setup one-shot ;
- lecture technique de conteneur / accès ;
- maintenance historique.

Décision :
**aucune action rare ou risquée ne doit apparaître au même niveau visuel que la migration normale.**

### 7.4 Séparation claire des blocs

#### Bloc 1 — Diagnostic
Objectif : savoir si la DB cible est lisible et qualifiée.

Affiche :
- DB cible ;
- mode d’accès ;
- état diagnostic ;
- dernières vérifications ;
- remédiation courte.

#### Bloc 2 — Backup
Objectif : savoir si la sécurité minimale est assurée avant action sensible.

Affiche :
- dernier backup ;
- horodatage ;
- cible concernée ;
- état `backup récent / absent / ancien`.

#### Bloc 3 — Migration
Objectif : montrer sans ambiguïté quelle release migrera quelle DB.

Affiche :
- release sélectionnée ;
- release active distante ;
- release utilisée pour migration ;
- DB cible ;
- bouton `Migrer le release`.

#### Bloc 4 — Clonage
Objectif : préparer une DB non-prod à partir d’une source identifiée.

Affiche :
- DB source ;
- artefact source ;
- DB cible ;
- bouton de préparation / restauration.

#### Bloc 5 — Restauration
Objectif : exposer clairement les opérations exceptionnelles.

Affiche :
- cible ;
- artefact utilisé ;
- avertissement ;
- confirmation renforcée.

### 7.5 Affichage sans ambiguïté des objets critiques
Les objets suivants doivent être visibles et distincts :

| Objet | Affichage cible | Règle |
|---|---|---|
| Release sélectionnée | `Release visée : 20260404-014000` | globale et constante |
| Release active distante | `Active distante : 20260403-231500` | globale et constante |
| Release utilisée pour migration | `Migration appliquée au release : 20260404-014000` | dans le bloc migration |
| DB source | `DB source : export production du 2026-04-05` ou `DB source : v2` | seulement dans clonage / restauration |
| DB cible | `DB cible : ttm_api (Préprod)` | dans le bandeau + dans tous les blocs DB principaux |

Décision :
**la page DB ne doit jamais afficher “source” ou “cible” sans préfixe explicite.**

### 7.6 Règles de simplification UI de la page DB
- ne pas afficher `source`, `cible`, `release`, `artefact` dans une même ligne non qualifiée ;
- ne pas laisser la migration visible si la DB cible n’est pas confirmée ;
- ne pas laisser la restauration visible au premier niveau ;
- ne pas faire de la page DB une page de logs ;
- ne pas mélanger le diagnostic et l’action dans un même bloc confus.

### 7.7 Décision produit/UI finale pour la page DB
**La page Base de données doit être conçue comme une page de sûreté et de compatibilité, pas comme un panneau d’outillage DB.**

---

## 8. Règles de sécurité cognitive

Ces règles doivent devenir des invariants produit/UI.

### 8.1 Une action bloquée doit être désactivée
Si un diagnostic bloque une action sensible, l’action doit être désactivée.
Pas seulement accompagnée d’un warning.

### 8.2 La vérité affichée doit être unique
Une même information critique ne doit pas exister sous plusieurs formes contradictoires.
Exemple :
- une release ne peut pas être à la fois “non sélectionnée” et utilisée avec succès ;
- une cible ne peut pas être ambiguë selon la page.

### 8.3 L’interface doit dire si l’état est frais
Chaque état important doit dire s’il est :
- frais ;
- en cours d’actualisation ;
- potentiellement obsolète.

### 8.4 Toute action à risque doit rappeler son contexte
Avant validation d’une action sensible, rappeler :
- release visée ;
- active distante ;
- cible ;
- profil actif ;
- DB cible si concernée ;
- conséquence concrète.

### 8.5 Les informations critiques doivent rester visibles pendant les chargements
Pendant un chargement ou une reconnexion, l’utilisateur doit conserver :
- le contexte global ;
- le dernier état utile ;
- le statut du chargement.

### 8.6 Les états système et les états pipeline ne doivent pas être confondus
Exemple :
- `API distante arrêtée` est un état système ;
- `Validation distante bloquée` est un état pipeline.

Les deux doivent être reliés, mais pas fusionnés.

### 8.7 Le prochain pas sûr doit toujours être explicite
Chaque page principale doit afficher un bloc final :
- `Prochain pas recommandé`.

### 8.8 Les détails experts doivent être opt-in
Les détails experts ne doivent pas être visibles par défaut si :
- ils n’aident pas la majorité des parcours ;
- ils augmentent la charge mentale ;
- ils introduisent un risque de clic prématuré.

### 8.9 Un changement de contexte doit invalider ce qui est obsolète
Si la release, la cible ou le profil changent :
- le pipeline doit repasser certaines étapes en `Obsolète` ;
- les validations précédentes ne doivent pas continuer à sembler valides.

### 8.10 Une page ne doit jamais demander un raisonnement latéral inutile
L’utilisateur ne doit pas avoir à se dire :
- “je suis sur Build mais je dois comprendre Runtime pour savoir si je peux continuer” ;
- “je suis sur Releases mais je dois relire Base de données pour savoir si activer est prudent”.

L’outil doit porter ce raisonnement pour lui.

---

## 9. Plan concret de mise en œuvre

## 9.1 Lot 1 : quick wins indispensables

### Objectif
Sécuriser immédiatement la lecture et rendre le parcours compréhensible sans refonte lourde.

### Changements inclus
- mise en place du bandeau global unique ;
- correction de toutes les incohérences d’état critiques ;
- ajout du bloc `Prochain pas recommandé` sur les pages clés ;
- renforcement des confirmations sensibles ;
- normalisation des statuts (`Prêt`, `Bloqué`, `Obsolète`, etc.) ;
- repli par défaut des blocs experts les plus bruyants.

### Bénéfice attendu
- réduction rapide du risque d’erreur ;
- lecture plus fiable ;
- sentiment de contrôle renforcé.

### Complexité estimée
**Moyenne**, avec forte rentabilité.

## 9.2 Lot 2 : simplification structurelle

### Objectif
Réorganiser les pages autour du parcours réel de promotion.

### Changements inclus
- repositionnement visible de `Profils` vers `Env` ;
- recentrage de `Déploiement` sur l’action d’envoi ;
- recentrage de `Releases` sur activation / rollback ;
- recentrage de `Runtime` sur validation opérationnelle ;
- refonte de premier niveau de `Base de données` ;
- clarification des boutons principaux / secondaires page par page.

### Bénéfice attendu
- baisse forte de la charge cognitive ;
- meilleure compréhension de chaque page ;
- meilleur enchaînement entre pages.

### Complexité estimée
**Élevée**, mais structurante.

## 9.3 Lot 3 : amélioration produit transverse

### Objectif
Faire du Devtools un vrai cockpit de promotion de release.

### Changements inclus
- ajout de la vue pipeline transverse sticky ;
- gestion explicite des statuts `Obsolète` et `Non requis` ;
- convergence des trois vérités `contexte / système / pipeline` ;
- état consolidé global `Prêt / À vérifier / Bloqué` ;
- harmonisation complète de la fraîcheur et de la reconnexion ;
- clarification explicite de la preview et de la validation réelle.

### Bénéfice attendu
- outil beaucoup plus narratif ;
- meilleure confiance opératoire ;
- décisions d’activation plus sûres.

### Complexité estimée
**Élevée**, mais c’est le vrai saut produit.

---

## 10. Version cible ultra synthétique

### 10 décisions produit/UI majeures
1. Le Devtools devient un cockpit de promotion de release, pas une collection de pages techniques.
2. La release est l’unité centrale de lecture et d’action.
3. Un bandeau global obligatoire affiche partout le contexte critique.
4. Une vue pipeline transverse montre l’avancement réel du release.
5. `Profils` devient visuellement `Env`.
6. `Déploiement` se limite au push distant sans activation.
7. `Releases` devient la page claire d’activation et de rollback.
8. `Runtime` se recentre sur la validation opérationnelle, pas sur le debug.
9. `Base de données` adopte un premier niveau simple et un second niveau expert.
10. Toute action sensible est gouvernée par une vérité unique, fraîche et non contradictoire.

### Résumé final
Le Devtools cible doit devenir un outil de promotion de release lisible comme un parcours continu : je choisis une release, je vois son état, je comprends où j’en suis, je sais ce qui me bloque, et l’outil me propose le prochain pas sûr. Les pages spécialisées restent, mais elles ne vivent plus comme des silos. Elles deviennent des vues cohérentes d’une même progression. La simplicité cognitive, la fiabilité du contexte et la clarté du séquencement doivent désormais primer sur l’exposition brute des capacités techniques.