---
description: Mettre à jour le journal des mises à jour pour tout changement visible utilisateur (#412)
alwaysApply: true
---

# Journal des mises à jour utilisateur (#412)

Pour **tout SUIVI ou modification avec impact utilisateur visible** :

1. Ajouter une entrée vulgarisée dans `database/data/journal_mises_a_jour_post_2026_06_12.php`
2. **Dans le même commit** que le code fonctionnel (pas de rattrapage séparé type #561)
3. Lire les 3–4 **dernières entrées** du fichier et reproduire **exactement** leur structure (clés, ordre, format) — ne pas inventer de nouvelles clés
4. Vérifier l'absence de **doublon** avec l'existant avant d'ajouter

## Contenu de l'entrée

| Clé | Règle |
|-----|-------|
| `code` | Identifiant unique kebab-case + date (`feature-2026-07-06`) |
| `date_maj` | Date du commit (`YYYY-MM-DD`) ; `heure_maj` optionnel si le format récent du fichier l'utilise |
| `sujet` | Clé métier pour fusion des entrées contiguës (ex. `commercialisation_grille`, `taches_suivi`) |
| `titre` | Court, langage utilisateur, non technique |
| `description` | Bénéfice concret pour l'utilisateur |
| `public_groupes` | Codes M365 (`GS_ENVOL`, `GS_COMPTABILITE`…) ou `tous` |

## Ne pas créer d'entrée pour

- Correctifs techniques invisibles (fatal 500, import manquant, typo interne, migration silencieuse…)
- Refactors sans changement perceptible par l'utilisateur

## Avant push

```bash
php -l database/data/journal_mises_a_jour_post_2026_06_12.php
```

## Après déploiement OVH

```bash
php artisan view:clear
php artisan journal:sync
```

Vérifier visuellement le panneau Journal dans l'application.