Exploiter

Exploiter

Opérations courantes pour l'équipe informatique, une fois l'application installée. Les commandes se lancent dans le dossier de docker-compose.yml. Pour une installation sans Docker, les mêmes opérations sont décrites dans Installer sans Docker.

Choisir une version

Les versions sont numérotées (1.0.0, 1.1.0…) et décrites sur la page Releases du dépôt GitHub, avec leurs nouveautés. Chaque version publie ces étiquettes d'image :

• 1.1.0 : cette version précise ;
• 1.1 : la dernière correction de la 1.1 ;
• latest : la dernière version publiée.

Chaque fusion sur la branche main publie aussi main et sha-<7 caractères>, pour tester avant une version : ces images ne sont pas numérotées et l'indicateur de mise à jour ne les compare pas.

En production, fixer une version précise dans MEP_IMAGE (ghcr.io/soladevsolide/gestion-mep:1.1.0) plutôt que latest. On sait ainsi ce qui tourne, et on peut revenir à la version précédente.

Savoir qu'une version est disponible

L'application consulte deux fois par jour la dernière version publiée sur GitHub (api.github.com, en lecture, sans rien envoyer de ses données). Quand elle est plus récente que celle qui tourne, les administrateurs voient « Mise à jour … disponible » dans la barre latérale ; l'onglet Version de la console d'administration donne le détail, le lien vers les nouveautés et un bouton « Vérifier maintenant ». Tout le monde voit la version en cours en bas du menu utilisateur.

Un serveur sans accès à Internet affiche « GitHub est injoignable » dans cet onglet ; VERIFIER_MISES_A_JOUR=false coupe complètement la vérification.

Mettre à jour

Deux façons : depuis la console d'administration, si le service de mise à jour est activé (voir Mettre à jour depuis la console), ou à la main :

1. Changer MEP_IMAGE dans .env.

2. Appliquer :

   docker compose pull app
   docker compose up -d app

3. Vérifier /api/sante/prete (ou docker compose ps : healthy) et les journaux (docker compose logs --tail 100 app).

Si la version change le fichier Compose (signalé dans les notes de version), reprendre aussi le docker-compose.yml joint à la nouvelle version.

Le schéma de la base est migré au démarrage du nouveau conteneur, avec une sauvegarde automatique :

1. Si des migrations sont en attente et que la base contient déjà des données, l'application écrit d'abord une archive de la base et des pièces jointes dans le volume sauvegardes (avant-mise-a-jour-AAAAMMJJ-HHMMSS.tar.gz). Si la sauvegarde échoue (disque plein, dossier non accessible), la migration n'est pas lancée et l'application ne démarre pas.
2. Les migrations sont appliquées.
3. Des contrôles internes comparent les données à la sauvegarde : aucune table disparue, aucune table avec moins de lignes, aucun fichier de pièce jointe manquant. Une table qu'une migration reprend volontairement dans une autre n'est pas comptée comme disparue : ses lignes s'ajoutent à celles attendues dans la table d'arrivée (par exemple, depuis la version 1.6.0, les livrables deviennent des objets impactés : la table Livrables disparaît et ses lignes doivent se retrouver dans ObjetsImpactes). Si la table d'arrivée a moins de lignes que prévu, ou si une table disparaît sans reprise, c'est un écart.
4. Si les contrôles passent, la sauvegarde est supprimée. Sinon, elle est conservée, l'écart est écrit dans les journaux et dans le journal d'administration (type donnees.controle-echoue), et l'application démarre quand même : voir Revenir à la version précédente.

Le résultat est inscrit dans le journal d'administration dans les deux cas. Une mise à jour sans changement de schéma ne fait pas de sauvegarde : elle ne touche pas aux données. gestion-mep migrer suit le même déroulé sans démarrer l'application.

Éviter de mettre à jour pendant une MEP en cours : les utilisateurs sont déconnectés le temps du redémarrage. Les onglets restés ouverts proposent ensuite de recharger la page pour passer à la nouvelle version.

Mettre à jour depuis la console

Un petit service facultatif, mise-a-jour, permet à un administrateur de cliquer « Mettre à jour vers … » dans l'onglet Version de la console. Il est désactivé par défaut : c'est à l'équipe informatique de décider de l'activer, car il a accès à Docker sur le serveur.

Activer (dans le dossier de docker-compose.yml) :

1. Fixer une version publiée dans MEP_IMAGE (ghcr.io/soladevsolide/gestion-mep:1.9.0) : le service ne remplace que les images numérotées de ce dépôt. C'est déjà le cas avec les fichiers joints à la version (voir Installer), qui fixent aussi l'image du service à la même version (MEP_IMAGE_MISE_A_JOUR).
2. Ajouter COMPOSE_PROFILES=mise-a-jour dans .env.
3. docker compose pull mise-a-jour && docker compose up -d.

Le service a besoin du docker-compose.yml d'une version qui monte le dossier du projet (.:/projet) : il lance alors Compose depuis ce dossier, comme à la main, si bien que docker-compose.override.yml, .env et les montages relatifs (./charte.json) sont conservés à la recréation de l'application.

L'onglet Version affiche alors le bouton dès qu'une version plus récente est publiée. Pour désactiver : retirer la ligne de .env, puis docker compose stop mise-a-jour && docker compose rm -f mise-a-jour.

Déroulé d'une mise à jour :

1. L'administrateur confirme. L'application refuse tant qu'une MEP est en exécution, en recette ou en retour arrière, et inscrit la demande dans le journal d'administration.
2. Le service télécharge l'image de la nouvelle version. En cas d'échec, rien n'est changé.
3. Il arrête l'application et sauvegarde la base et les pièces jointes avec la version en place (avant-<version>-AAAAMMJJ-HHMMSS.tar.gz, heure UTC, dans le volume sauvegardes). Si la sauvegarde échoue, il relance la version en place : rien n'est changé.
4. Il écrit la nouvelle image dans MEP_IMAGE du fichier .env et fait migrer la base par la nouvelle version (migrer, avec sa sauvegarde automatique). La migration est attendue jusqu'au bout, quelle que soit sa durée : elle n'est jamais interrompue.
5. Il démarre la nouvelle version et attend qu'elle soit prête (sonde /api/sante/prete du HEALTHCHECK, MEP_ATTENTE_SANTE secondes au plus, 5 minutes par défaut). Un conteneur qui s'arrête ou redémarre pendant ce temps est un échec immédiat.
6. Si la migration ou le démarrage échoue, il arrête l'application, remet l'image précédente dans .env, recharge la sauvegarde de l'étape 3 et relance l'application : elle revient à l'état exact d'avant la mise à jour. Le message final dit ce qui a été fait ; si la restauration elle-même échoue, l'application reste arrêtée (pour ne pas tourner sur une base modifiée) et le message donne la sauvegarde à recharger à la main.
7. Après une mise à jour réussie, le service passe lui-même à la même version (MEP_IMAGE_MISE_A_JOUR dans .env) et se recrée en dernier, s'il utilise une image du même dépôt.

La sauvegarde de l'étape 3 est conservée : la supprimer du volume sauvegardes une fois la nouvelle version validée. L'avancement et le résultat s'affichent dans l'onglet Version ; le détail est dans docker compose logs mise-a-jour. Les utilisateurs sont déconnectés de l'arrêt (étape 3) au redémarrage (étape 5).

En ligne de commande, la même demande passe par le même service, avec les mêmes refus (service absent ou occupé, version qui n'est pas plus récente que celle en cours ou qui dépasse la dernière publiée, MEP en cours) :

docker compose exec app gestion-mep mettre-a-jour                         # version en cours, dernière version publiée, état du service
docker compose exec app gestion-mep mettre-a-jour --oui                   # demande l'installation de la dernière version publiée
docker compose exec app gestion-mep mettre-a-jour --oui --version 1.9.1   # une version précise, plus récente que celle en cours
docker compose logs -f mise-a-jour                                        # suivre l'installation

Sans le service, mettre-a-jour indique la marche à suivre manuelle (Mettre à jour).

Registre interne, sans GitHub

Sur un serveur sans accès à Internet, avec une copie des images dans un registre interne :

1. Copier dans le registre les images gestion-mep et gestion-mep-mise-a-jour de chaque version, sous le même nom de dépôt suivi de -mise-a-jour (par exemple registre.entreprise.fr/gestion-mep:1.9.0 et registre.entreprise.fr/gestion-mep-mise-a-jour:1.9.0).
2. Dans .env : MEP_DEPOT_IMAGE=registre.entreprise.fr/gestion-mep, MEP_IMAGE et MEP_IMAGE_MISE_A_JOUR sur ce registre, et VERIFIER_MISES_A_JOUR=false.
3. Demander la version par gestion-mep mettre-a-jour --oui --version x.y.z : sans vérification sur GitHub, toute version plus récente que celle en cours est acceptée, et le service vérifie qu'elle existe dans le registre avant de rien changer (sinon : « Téléchargement impossible », rien n'est changé). Le bouton de la console, lui, n'apparaît que lorsqu'une version publiée sur GitHub est connue.

Sécurité : le service monte le socket Docker (/var/run/docker.sock), ce qui revient à un accès administrateur à la machine, et le dossier du projet (pour réécrire .env). Il n'ouvre aucun port : il lit seulement, dans un volume partagé avec l'application, un fichier contenant un numéro de version (1.2.3), et ne peut installer que MEP_DEPOT_IMAGE:<version>. Son image est fixée à une version (jamais latest dans les fichiers joints aux versions). L'application, elle, n'a aucun accès à Docker.

Revenir à la version précédente

Le service de mise à jour le fait de lui-même quand la nouvelle version ne migre pas ou ne démarre pas (voir ci-dessus). À la main :

1. Remettre l'ancienne valeur de MEP_IMAGE dans .env.

2. Si la nouvelle version a modifié le schéma de la base, recharger la sauvegarde faite avant la mise à jour (les migrations ne sont pas annulées automatiquement). Elle n'existe plus si les contrôles étaient passés : utiliser alors la dernière sauvegarde. Les données saisies depuis seront perdues.

   docker compose stop app
   docker compose run --rm app importer /data/sauvegardes/avant-mise-a-jour-AAAAMMJJ-HHMMSS.tar.gz

3. docker compose up -d app.

Sauvegarder

Une archive contient la base et les pièces jointes, lues au même instant. Le volume cles est à sauvegarder aussi (copie du volume, par exemple avec la sauvegarde de la machine) : il contient les clés qui chiffrent les cookies de session et le secret de la connexion Microsoft. Le perdre déconnecte tous les utilisateurs et rend ce secret illisible : la connexion Microsoft ne fonctionne plus jusqu'à ce qu'un administrateur le saisisse de nouveau. Sur un nouveau serveur, sans la copie du volume, prévoir cette nouvelle saisie après l'importation.

docker compose exec app gestion-mep sauvegarder   # écrit /data/sauvegardes/sauvegarde-AAAAMMJJ-HHMMSS.tar.gz

# Copier les archives hors du conteneur, puis hors du serveur
docker compose cp app:/data/sauvegardes ./sauvegardes

À planifier chaque nuit (cron, tâche planifiée) et à copier hors du serveur ; supprimer ensuite les anciennes archives du volume sauvegardes. L'archive (.tar.gz) contient un fichier manifest.json (version, nombre de lignes par table, empreinte SHA-256 de chaque pièce jointe), une copie de chaque table et les fichiers des pièces jointes. Elle ne dépend pas de pg_dump et fonctionne aussi avec une base PostgreSQL externe.

La sauvegarde peut tourner pendant que l'application est utilisée : si une pièce jointe est supprimée pendant qu'elle s'écrit, elle recommence, pour que chaque pièce de la base ait son fichier dans l'archive. Une pièce dont le fichier manquait déjà sur le disque est signalée dans le journal et inscrite dans le manifeste.

Restaurer ou déménager

L'importation remplace toute la base et toutes les pièces jointes par le contenu d'une archive : restauration après incident, ou passage sur un autre serveur (installer l'application, puis importer l'archive de l'ancien serveur). L'application doit être arrêtée. docker compose run lance un conteneur ponctuel de l'image avec les mêmes volumes ; la commande y est passée sans le préfixe gestion-mep.

docker compose stop app
docker compose run --rm -v "$PWD/sauvegardes:/import:ro" app importer /import/sauvegarde-AAAAMMJJ-HHMMSS.tar.gz
docker compose up -d app

Pour une archive déjà présente dans le volume sauvegardes (sauvegarde de la nuit, sauvegarde automatique conservée), sauvegardes lister donne les archives disponibles et sauvegardes restaurer fait la même importation, avec une confirmation explicite (--oui). Elle refuse de s'exécuter tant que l'application est en marche (autre connexion ouverte sur la base) : c'est pourquoi elle ne se lance pas par docker compose exec, mais par docker compose run, application arrêtée.

docker compose exec app gestion-mep sauvegardes lister
docker compose stop app
docker compose run --rm app sauvegardes restaurer sauvegarde-AAAAMMJJ-HHMMSS.tar.gz --oui
docker compose up -d app

Déroulé :

1. L'archive est vérifiée avant de toucher à quoi que ce soit : contenu attendu uniquement, empreinte de chaque pièce jointe, version compatible (une archive d'une version plus récente de l'application est refusée : mettre l'application à jour d'abord), et place sur le disque (l'extraction s'arrête avant de laisser moins de 1 Go libre). Une archive de la même version que la base doit contenir toutes ses tables, avec toutes leurs colonnes.
2. Si la base contient déjà des données, elles sont sauvegardées (avant-import-AAAAMMJJ-HHMMSS.tar.gz dans le volume sauvegardes).
3. La base est remise au schéma de l'archive. L'archive doit en couvrir toutes les tables et colonnes (sinon l'importation s'arrête avant de charger quoi que ce soit, et la sauvegarde de l'étape 2 est gardée). Les données et les pièces jointes sont rechargées, puis les migrations plus récentes que l'archive sont appliquées.
4. Des contrôles internes vérifient que tout le contenu de l'archive est présent : même nombre de lignes par table, tous les fichiers de pièces jointes, et un fichier pour chaque pièce jointe de la base. Après les migrations plus récentes que l'archive, une table reprise par une migration dans une autre est contrôlée avec sa table d'arrivée, comme lors d'une mise à jour.
5. Si les contrôles passent, la sauvegarde de l'étape 2 est supprimée. Sinon, elle est conservée, la commande renvoie le code 1 et indique le fichier à réimporter pour revenir à l'état d'avant.

Tester une restauration au moins une fois, sur une machine de recette, avant d'en avoir besoin.

Commandes d'administration

L'image contient une commande gestion-mep pour administrer sans navigateur : tout ce qui se règle dans la console d'administration se règle aussi en ligne de commande. Les commandes appliquent les mêmes règles que la console (nom affiché qui imite un autre compte, dernier administrateur, système utilisé…) et leurs modifications sont inscrites dans le journal d'administration, avec l'auteur « Ligne de commande ».

gestion-mep aide donne la liste complète. Codes de retour : 0 succès, 1 échec (message sur la sortie d'erreur), 2 commande mal formée. L'option --json (à placer n'importe où) donne une sortie JSON pour les scripts, sur les commandes lister, afficher (dont equipes afficher et charte afficher), expertises, journal, config afficher et mettre-a-jour.

Console d'administration	Ligne de commande
Comptes	gestion-mep comptes …
Équipes	gestion-mep equipes …
Connexion unique	gestion-mep sso … (Connexion Microsoft)
Paramètres : réglages du serveur, approbations	gestion-mep reglages … (ci-dessous)
Paramètres : critères go / no-go	gestion-mep criteres …
Charte visuelle	gestion-mep charte … (ci-dessous)
Journal	gestion-mep journal
Version	gestion-mep version, gestion-mep mettre-a-jour
Menu Paramètres : systèmes, résolutions types	gestion-mep systemes …, gestion-mep resolutions …
Bandeau « Mode démonstration » : réinitialiser	gestion-mep demo reinitialiser --oui (ci-dessous)

Comptes

docker compose exec app gestion-mep comptes lister
docker compose exec app gestion-mep comptes afficher jdupont                     # rôle, contact, expertises
docker compose exec app gestion-mep comptes creer jdupont --nom "Jean Dupont" --role "DBA" --contact "poste 1234" --admin
docker compose exec app gestion-mep comptes modifier jdupont --nom "J. Dupont" --admin non --contact "jean.dupont@entreprise.fr"
docker compose exec app gestion-mep comptes modifier jdupont --ajouter-expertise BDD --detail "Base clients" --retirer-expertise API
docker compose exec app gestion-mep comptes expertises jdupont
docker compose exec app gestion-mep comptes reinitialiser-mdp jdupont
docker compose exec app gestion-mep comptes desactiver jdupont
docker compose exec app gestion-mep comptes reactiver jdupont
docker compose exec app gestion-mep comptes relier jean.dupont@entreprise.fr jdupont --desactiver
docker compose exec app gestion-mep comptes delier jean.dupont@entreprise.fr

creer et reinitialiser-mdp affichent un mot de passe provisoire, une seule fois : le transmettre par un canal sûr. Il doit être changé à la première connexion. Avec modifier, seules les options données changent ; --detail s'applique à l'--ajouter-expertise qui le précède (une expertise déjà présente est mise à jour). Le dernier administrateur actif ne peut être ni désactivé ni rétrogradé, et un nom affiché ne peut pas reprendre le nom ou l'identifiant d'un autre compte.

relier <login> <login-principal> relie deux comptes d'une même personne : rien n'est fusionné ni supprimé, le compte relié s'affiche sous le nom du compte principal, et --desactiver le désactive en plus. Un seul niveau de liaison (le compte principal n'est relié à aucun autre). delier défait la liaison. comptes lister et comptes afficher indiquent les comptes reliés et les équipes. Voir Administrer.

Administrateur perdu ou bloqué : comptes reinitialiser-mdp <login> (puis comptes reactiver <login> s'il était désactivé), ou comptes creer secours --admin.

Équipes

docker compose exec app gestion-mep equipes lister
docker compose exec app gestion-mep equipes creer "Exploitation" --description "Équipe d'astreinte"
docker compose exec app gestion-mep equipes ajouter Exploitation jdupont mmartin     # un ou plusieurs logins
docker compose exec app gestion-mep equipes retirer Exploitation mmartin
docker compose exec app gestion-mep equipes afficher Exploitation                    # description et membres
docker compose exec app gestion-mep equipes modifier Exploitation --nom "Exploitation N2" --description "…"
docker compose exec app gestion-mep equipes supprimer "Exploitation N2"              # comptes et MEP inchangés

Une équipe se désigne par son nom (sans tenir compte des majuscules, entre guillemets s'il contient des espaces) ou son identifiant. Une personne peut appartenir à plusieurs équipes. Chaque commande est inscrite au journal d'administration.

Catalogue des systèmes et critères go / no-go

docker compose exec app gestion-mep systemes lister
docker compose exec app gestion-mep systemes ajouter CRM --description "Relation client" --cible "crm01.entreprise.fr"
docker compose exec app gestion-mep systemes modifier CRM --nom "CRM Ventes" --actif non
docker compose exec app gestion-mep systemes supprimer "CRM Ventes"       # désactivé au lieu d'être supprimé s'il est utilisé
docker compose exec app gestion-mep systemes afficher BDD                   # fiche : environnements, catégories et objets
docker compose exec app gestion-mep systemes historique BDD                 # MEP qui l'ont touché : date, état, échecs ; --excel /tmp/historique.xlsx
docker compose exec app gestion-mep systemes environnement BDD Préproduction --cible "pg-preprod"
docker compose exec app gestion-mep systemes environnement BDD Production --production oui
docker compose exec app gestion-mep systemes categorie BDD "Tables"         # --renommer "…", --retirer (avec ses objets)
docker compose exec app gestion-mep systemes objet BDD "Tables" clients --type Table --libelle "Fiches clients"
docker compose exec app gestion-mep categories lister                       # catégories proposées par défaut ; ajouter "<nom>", retirer "<nom>"

docker compose exec app gestion-mep criteres lister                         # numérotés : n° 1, 2…
docker compose exec app gestion-mep criteres ajouter "Astreinte prévenue" --ordre 5
docker compose exec app gestion-mep criteres modifier 3 --libelle "Astreinte prévenue et joignable" --actif non
docker compose exec app gestion-mep criteres supprimer 3

Un système se désigne par son nom (sans tenir compte des majuscules), un critère par son numéro dans criteres lister ou par son identifiant. Le nombre minimum d'approbations avant le Go est un réglage : gestion-mep reglages definir approbations-minimum 2.

Résolutions types

docker compose exec app gestion-mep resolutions lister --systeme BDD        # --inactives : aussi les fiches désactivées
docker compose exec app gestion-mep resolutions afficher "BDD : utilisateur applicatif retiré des droits"
docker compose exec app gestion-mep resolutions supprimer 3f2a9c1e          # identifiant (8 premiers caractères) ou titre
docker compose exec -T app gestion-mep resolutions exporter > resolutions.json
docker compose exec -T app gestion-mep resolutions importer - --essai < resolutions.json
docker compose exec -T app gestion-mep resolutions importer - --ignorer-existantes < resolutions.json

L'export (JSON) contient les résolutions actives ; leurs systèmes y sont désignés par leur nom, pour passer d'un serveur à l'autre. L'import contrôle chaque fiche comme la saisie dans l'application (titre, symptômes, diagnostic, au moins une correction, vérification, systèmes connus du catalogue) et affiche ce qui est créé, remplacé, ignoré ou refusé, avec le motif ; une fiche refusée n'empêche pas les autres, et la commande renvoie alors le code 1. Une fiche dont le titre existe déjà est refusée, sauf --remplacer (nouvelle version de la fiche, l'historique est gardé) ou --ignorer-existantes. --essai contrôle sans rien enregistrer. Une résolution déjà liée à une étape ou exécutée est désactivée au lieu d'être supprimée.

MEP et journal

docker compose exec app gestion-mep meps lister --phase execution           # preparation, execution, recette, retour-arriere, cloturee, annulee ; --modeles
docker compose exec app gestion-mep meps lister --equipe Exploitation       # MEP dont une personne fait partie de l'équipe
docker compose exec app gestion-mep meps lister --type simplifiee           # MEP simplifiées seulement (complete : complètes)
docker compose exec app gestion-mep meps lister --phase execution --recherche paie --excel /tmp/meps.xlsx
docker compose exec app gestion-mep meps lister --systeme BDD --environnement Production --echec   # échec d'étape sur BDD en production
docker compose exec app gestion-mep meps lister --personne alice --role pilote,executant --du 2026-01-01
docker compose exec app gestion-mep meps lister --etat incidents,repliee --au 2026-09-30
docker compose exec -T app gestion-mep meps exporter 3f2a9c1e > mep-3f2a9c1e.json
docker compose exec app gestion-mep meps excel 3f2a9c1e etapes /tmp/etapes.xlsx   # preparation, etapes, retour-arriere, recette, objets, journal, rapport
docker compose exec app gestion-mep journal --depuis 2026-10-01 --limite 500

La liste indique le type de chaque MEP (complète ou simplifiée). meps exporter écrit la MEP complète (identité et type, choix du plan de retour arrière, plan, étapes avec leur type de fin et leur résultat constaté, preuves, approbations, go / no-go, recette, bilan, liste des pièces jointes), le suivi de ses tests unitaires (testsUnitaires : faits, non faits, résultats) et tout son journal, dans l'ordre chronologique : de quoi archiver une intervention ou répondre à un audit. Les fichiers des pièces jointes restent dans les sauvegardes. Avec -T, docker compose exec transmet la sortie telle quelle, sans retours chariot ajoutés : à utiliser pour rediriger vers un fichier de l'hôte. L'exportation est inscrite dans le journal d'administration.

meps lister a les filtres de la recherche des MEP de la page d'accueil, avec les mêmes règles : --systeme (nom du catalogue ; un nom inconnu du catalogue désigne un système saisi à la main dans les MEP), --environnement (sur ces systèmes), --echec (échec d'étape survenu sur ces systèmes), --equipe, --personne (login, nom ou identifiant ; tous les comptes reliés de la personne comptent) et --role (pilote, suppleant, responsable, executant, approbateur), --etat (preparation, reportee, execution, recette, retour-arriere, reussie, incidents, repliee, echec, annulee), --du et --au (jour du Go, à défaut de la création, bornes incluses). Les listes sont séparées par des virgules. Il n'y a pas de commande de suppression d'une MEP : un administrateur la supprime dans l'application (MEP jamais lancée ou modèle), et une MEP lancée s'annule (voir Cycle de vie). Le tableau donne l'état, le jour, les échecs survenus et les systèmes de chaque MEP, les plus récentes d'abord. systemes historique <SYSTÈME> donne toutes les MEP qui ont touché un système du catalogue, avec leurs environnements sur ce système et leurs échecs d'étape ; --excel écrit le classeur de l'onglet « Historique des MEP » de sa fiche.

--excel <fichier.xlsx> écrit la liste en classeur Excel, avec les mêmes filtres (--recherche cherche, sans tenir compte des accents ni de la casse, dans l'outil, la version, l'objet, les personnes et les systèmes, comme la page d'accueil) et une feuille « Échecs ». meps excel <id> <vue> écrit le classeur du bouton « Exporter en Excel » de la vue (journal complet, sans filtre) ; sans fichier, il prend le nom proposé par l'application, dans le dossier courant. Le fichier est écrit dans le conteneur : le récupérer sur l'hôte avec docker compose cp app:/tmp/etapes.xlsx .. meps excel <id> rapport écrit le rapport de fin d'une MEP clôturée (code 1 avant la clôture). Chaque export d'une vue est inscrit dans le journal d'administration (type mep.exportee). Voir Exporter en Excel. journal donne les 200 derniers événements d'administration, les plus récents d'abord.

Exploitation

docker compose exec app gestion-mep config afficher     # configuration lue au démarrage, secrets masqués
docker compose exec app gestion-mep config verifier     # base, migrations, dossiers, administrateurs, mots de passe d'exemple ; code 1 si problème
docker compose exec app gestion-mep migrer              # migrations seules, sans démarrer l'application (avec sauvegarde et contrôles)
docker compose exec app gestion-mep sauvegarder         # archive de la base et des pièces jointes
docker compose exec app gestion-mep sauvegardes lister  # archives du volume sauvegardes
docker compose exec app gestion-mep mettre-a-jour       # nouvelle version ? (--oui : l'installer, voir Mettre à jour depuis la console)
docker compose exec app gestion-mep version

config afficher montre ce qui ne change qu'en modifiant .env puis en recréant le conteneur (environnement, adresse d'écoute, base, dossiers, premier administrateur) ; les mots de passe et le secret de la connexion unique n'y apparaissent jamais (« défini (masqué) »). Les réglages modifiables sans redémarrage sont dans reglages lister ; config afficher --json réunit les deux. La restauration d'une archive est décrite dans Restaurer ou déménager.

Mode démonstration

Avec DEMO=true seulement (sinon la commande est refusée, code 1) :

docker compose exec app gestion-mep demo reinitialiser --oui

Remet la base dans l'état d'une base neuve en démonstration : comptes alice, bob, claire (mot de passe demo), MEP de démonstration, catalogue, résolutions types, critères, paramètres et réglages recréés ; journaux vidés ; fichiers de pièces jointes supprimés. Tout se fait dans une transaction, application en marche : les sessions ouvertes sont refusées à la requête suivante et les réglages reviennent aux valeurs de .env sous 10 secondes. Sans --oui, la commande explique ce qu'elle ferait et s'arrête. Le journal d'administration repart d'une seule ligne « Démonstration réinitialisée par la ligne de commande ». Même opération que le bouton du bandeau de l'application (voir Démarrage rapide).

Chaque connexion rapide (clic sur un compte de démonstration à l'écran de connexion) est écrite dans les journaux de l'application (docker compose logs app), comme les refus. Hors démonstration, les routes /api/demo… n'existent pas (404) et rien de tout cela n'apparaît.

Modifier un réglage

Les réglages du serveur (adresse publique, réseaux du proxy, HTTPS obligatoire, pièces jointes, connexions, mises à jour, lien de signalement) ont leur valeur de départ dans .env. On les modifie ensuite sans redémarrage, dans la console (onglet Paramètres) ou en ligne de commande :

docker compose exec app gestion-mep reglages lister
docker compose exec app gestion-mep reglages definir url-publique https://mep.entreprise.fr
docker compose exec app gestion-mep reglages definir pieces-taille-max-mo 50
docker compose exec app gestion-mep reglages definir lien-signalement ""     # valeur vide : lien masqué
docker compose exec app gestion-mep reglages retablir url-publique           # revient à la valeur de .env
docker compose exec app gestion-mep reglages definir approbations-minimum 2

Le nom d'un réglage est celui de sa variable .env, en minuscules avec des tirets (URL_PUBLIQUE → url-publique). Une valeur modifiée est enregistrée dans la base (elle suit donc les sauvegardes et les restaurations) et remplace celle de .env ; l'application l'applique dans les 10 secondes. Chaque modification est inscrite dans le journal d'administration.

Les plafonds des pièces jointes (taille d'un fichier, total par MEP, dépôts d'un compte sur 24 heures, espace libre minimal) sont vérifiés à chaque dépôt, sans tout recevoir d'abord : un dépôt dont la taille annoncée dépasse la place restante est refusé avant d'être lu, et un dépôt envoyé sans taille annoncée est arrêté dès qu'il dépasse un plafond (413 pour la taille d'un fichier, 422 pour le total de la MEP, 429 pour le compte, 507 pour le disque). Rien n'est gardé d'un dépôt refusé, ni le fichier ni la place réservée.

Charte visuelle

Les couleurs de l'application et des exports Excel (voir Administrer) ont leur valeur de départ dans un fichier charte.json, facultatif :

• avec Docker, charte.json à côté de docker-compose.yml, monté en lecture seule (décommenter la ligne ./charte.json:/etc/gestion-mep/charte.json:ro du service app, puis docker compose up -d) ;
• sans Docker, /etc/gestion-mep/charte.json sous Linux, C:\ProgramData\GestionMep\charte.json sous Windows ;
• la variable CHARTE_FICHIER donne un autre emplacement.

Seule la primaire est obligatoire. Exemple complet : installation/charte.exemple.json (joint aux archives de l'installation sans Docker) ; le schéma JSON est publié par l'application (/api/charte/schema.json), pour l'aide à la saisie des éditeurs.

{
  "$schema": "https://mep.entreprise.fr/api/charte/schema.json",
  "version": 1,
  "nom": "Groupe Horizon",
  "couleurs": { "primaire": "#0F766E", "secondaire": "#1B2A41", "tertiaire": "#C026D3" },
  "menuLateral": "secondaire",
  "gris": "teintes"
}

Clé	Valeurs	Par défaut
version	1	1
nom	texte, 80 caractères au plus	« Charte par défaut »
couleurs.primaire	#RRGGBB ou #RGB (obligatoire)
couleurs.secondaire	couleur	#0D0E1A
couleurs.tertiaire	couleur, ou "primaire" pour suivre la primaire	"primaire"
menuLateral	"pages" (comme les pages) ou "secondaire"	"pages"
gris	"froids", "purs", "chauds" ou "teintes"	"froids"
sombre.primaire, sombre.secondaire, sombre.tertiaire	couleur imposée au thème sombre	calculée
etats.succes, etats.avertissement, etats.erreur, etats.info	couleur d'état	couleurs standard

Le fichier est relu toutes les 10 secondes : une modification s'applique sans redémarrage, dans la minute sur les écrans ouverts. Un JSON illisible, une version inconnue, une couleur ou une valeur invalide rendent le fichier invalide : il est ignoré (charte par défaut), l'erreur est écrite dans les journaux de l'application et affichée dans la console. Une clé inconnue est seulement ignorée, et un contraste faible n'est qu'un avertissement.

La charte enregistrée dans la console, ou par les commandes ci-dessous, remplace le fichier ; retablir l'efface pour revenir au fichier (ou à la charte par défaut).

docker compose exec app gestion-mep charte afficher                 # charte en vigueur, origine, version sombre, lisibilité (--json)
docker compose exec -T app gestion-mep charte exporter > charte.json   # ou : charte exporter <fichier>
docker compose exec -T app gestion-mep charte verifier - < charte.json   # erreurs et avertissements ; code 1 si invalide
docker compose exec -T app gestion-mep charte importer - --essai < charte.json   # vérifie sans rien enregistrer
docker compose exec -T app gestion-mep charte importer - < charte.json   # enregistre (remplace le fichier)
docker compose exec app gestion-mep charte definir primaire 0F766E  # un rôle ou un état : primaire, secondaire, tertiaire, succes, avertissement, erreur, info
docker compose exec app gestion-mep charte definir tertiaire primaire   # la tertiaire suit la primaire
docker compose exec app gestion-mep charte retablir                 # efface la charte de la console

Sans argument, charte verifier contrôle la charte en vigueur et le fichier (code 1 si le fichier est invalide) ; config verifier le signale aussi. Dans un shell, # commence un commentaire : écrire la couleur sans # ou entre guillemets. Chaque enregistrement est inscrit dans le journal d'administration.

Surveiller

• Santé : deux sondes, sans session.
  • GET /api/sante (vivacité) répond 200 {"statut":"ok"} dès que le processus répond, sans rien vérifier d'autre.
  • GET /api/sante/prete (disponibilité) répond 200 avec {"statut":"prete","base":"ok","schema":"ok","echeances":"ok"} quand l'application peut servir : base joignable, schéma de la base égal à celui de la version (migrations-en-attente, ou plus-recent après un retour à une version précédente sans recharger la sauvegarde), et surveillance des échéances passée depuis moins de 5 minutes (en-retard sinon). Sinon, 503 avec le même détail. C'est elle que l'image interroge (HEALTHCHECK, colonne STATUS de docker ps : healthy), et celle à donner à un répartiteur de charge ou à une supervision. Pendant la sauvegarde et la migration du démarrage, l'application ne répond pas encore : unhealthy y est normal.
• Journaux : docker compose logs -f app. Les erreurs imprévues y sont écrites avec leur pile d'appels ; l'utilisateur ne voit qu'un message générique.
• Audit : chaque action sur une MEP est horodatée et attribuée dans l'onglet Journal de la MEP ; les actions d'administration sont dans le journal de la console d'administration.
• Pièces jointes orphelines : au démarrage, un fichier de pièce jointe sans enregistrement en base (application arrêtée pendant un dépôt) et vieux de plus d'une heure est déplacé dans le sous-dossier orphelins du volume pieces-jointes, et le nombre est écrit dans les journaux. Rien n'est supprimé : vider ce dossier à la main après vérification.
• Échéances : chaque minute, une tâche interne bascule en retour arrière les MEP dont l'échéance est dépassée (seulement celles qui ont un plan de retour arrière et une échéance). Une erreur de cette tâche apparaît dans les journaux.

Remettre à zéro

Supprime toutes les données (base, pièces jointes et sauvegardes du volume sauvegardes) :

docker compose down -v

En mode démonstration, gestion-mep demo reinitialiser --oui remet seulement la base dans son état initial, sans toucher aux sauvegardes ni arrêter l'application.