# CoolCare — Checklist post-déploiement 2026-05-02 **Lieu du fichier** : hors du repo coolcare-app (jamais commit / push) **Couvre** : 14 commits push entre 2026-05-01 et 2026-05-02 --- ## 1. Migrations BDD à appliquer manuellement (avec backup mysqldump préalable) ### 1a. Demandes devis "consulte" → "a_traiter" **Commit** : `1e73991` **Fichier** : `database/migration_demandes_devis_audit_consulte.sql` **État** : ✅ déjà push dans le repo, ❌ pas appliquée en prod ```bash ssh ubuntu@141.94.42.172 # Backup mysqldump --single-transaction -h ... -u cc_admin_app -p coolcare_app demandes_devis > /tmp/backup_demandes_devis_$(date +%F).sql # Application docker cp :/var/www/html/database/migration_demandes_devis_audit_consulte.sql /tmp/ mysql -h ... -u cc_admin_app -p coolcare_app < /tmp/migration_demandes_devis_audit_consulte.sql # Vérification SELECT COUNT(*) FROM demandes_devis WHERE statut = 'consulte'; # doit être 0 SELECT COUNT(*) FROM demandes_devis WHERE statut = 'a_traiter'; # doit avoir augmenté ``` ### 1b. Nettoyage frequence_controle_contrat orphelines **Commit** : `f86a4cc` (chantier 1) **Fichiers** : - `database/migration_machines_freq_contrat_orphelines.sql` - `database/migration_machines_freq_contrat_orphelines.rollback.sql` **État** : ✅ déjà push dans le repo, ❌ pas appliquée en prod **Important** : la migration n'est PAS bloquante (le code force NULL côté serveur via `MachineParamsBuilder::effectiveContractFreq`). Mais tant qu'elle n'est pas jouée, le bandeau d'alerte machines silencieuses peut afficher des fréquences de maintenance trompeuses (valeurs résiduelles en BDD). Volume estimé : ~105 machines à nettoyer (mesuré en local). --- ## 2. Vérifications fonctionnelles à faire en prod ### 2a. Bandeau d'alerte machines silencieuses **Commits** : `cc8a64e` + `cbd799f` + `d2951f3` + `ba898d6` - [ ] Aller sur `/admin/machines.php` connecté en admin - [ ] Vérifier qu'un bandeau orange s'affiche en haut si machines silencieuses - [ ] Cliquer "Voir le détail" → modal avec onglets par raison - [ ] Vérifier les compteurs par onglet (Incohérence site / Pas de date de fin / Pas d'ancre / Cycle terminé) - [ ] Click sur "Modifier la machine" → ouvre la modale d'édition de la machine concernée - [ ] Click sur "Modifier le site" → redirige vers `/admin/sites.php?edit=ID` et ouvre auto la modal d'édition ### 2b. Désactivation machine avec en retard légitimes **Commit** : `ba898d6` (chantier 1bis) - [ ] Identifier en prod une machine avec interventions `planifiee` en retard dans la fenêtre contractuelle (DASSAULT POINTE HAUTE par ex.) - [ ] Cliquer sur la pastille de statut pour désactiver - [ ] Vérifier que la modal de choix s'ouvre : "X intervention(s) en retard à régulariser" avec 3 boutons - [ ] Tester les 3 chemins : - **Garder** → machine désactivée, en retard préservées - **Supprimer aussi** → machine désactivée, en retard supprimées (= ancien comportement) - **Annuler** → rien ne se passe ### 2c. Modals CoolCareConfirm (remplacement confirm() natifs) **Commits** : `e5219cc` + `4805d4b` - [ ] Logout admin → modal stylée bleu "Se déconnecter" - [ ] Suppression intervention → modal rouge danger - [ ] Désactiver machine sans en retard → modal orange warning - [ ] Fermer modal machine avec form dirty → modal warning "Modifications non enregistrées" - [ ] Idem pour modal devis, technicien, gaz, site - [ ] Aucune fenêtre `localhost:8080 indique` (= confirm natif) ne doit apparaître ### 2d. Brouillon localStorage closeMachineModal **Commit** : `e896401` - [ ] `/admin/machines.php` → bouton "Ajouter une machine" - [ ] Saisir 2-3 champs (form devient dirty) - [ ] Fermer la modal → "Fermer sans enregistrer" - [ ] Re-cliquer "Ajouter une machine" - [ ] **Vérifier qu'aucune alerte "Brouillon disponible" n'apparait** (régression possible si le fix ne s'est pas déployé) ### 2e. UX page interventions admin **Commits** : `141b136` + `5151cff` - [ ] `/admin/interventions.php` : KPIs en flex compact, pas en grid grand format - [ ] Couleur "En retard" est rouge `#dc2626`, pas orange - [ ] Click sur un KPI applique le filtre correspondant - [ ] Bouton "Réinitialiser les filtres" purge tous les filtres - [ ] Plus aucun affichage de "Priorité" nulle part (admin, client portal, intervention_workflow_detail) - [ ] Plus aucun filtre `priorité` dans le dropdown ### 2f. Demandes techniciens **Commit** : `1e73991` - [ ] `/admin/demandes_devis.php` : H1 "Demandes de devis reçues lors d'interventions du technicien" - [ ] Filtre par défaut "À traiter" - [ ] Plus d'option "Consulté" dans le dropdown statut - [ ] Plus de colonne "Consulté par" - [ ] Sidebar : "Demandes techniciens" et "Devis commerciaux" (au lieu de "Demandes de devis" et "Devis") ### 2g. Polish UI **Commit** : `e1bec33` - [ ] Tableaux admin : police plus petite, contenus pas coupés - [ ] Headers triables : pas de retour à la ligne ("À traiter" sur 1 ligne) - [ ] Badges statut : pas de retour à la ligne - [ ] Page dashboard : KPIs en grille grand format conservée (pas en flex compact) - [ ] Page machines : barre de filtres alignée sur 1 seule ligne --- ## 3. Effets différés à surveiller ### 3a. 3ème série "Maintenance annuelle" qui apparaît au fil des modifs **Commit** : `d4866b5` (chantier 3) **Comportement** : pas de generation auto au push. À chaque fois qu'un admin modifie ou réactive une machine `sous_contrat_site=1` + ancre saisie, le moteur va générer (en plus des CERFA et maintenance supp existantes) une série "Maintenance annuelle" sur la date anniversaire de l'ancre. **Mesure prod** : 12 machines éligibles, 0 dont la modif générerait des occurrences ex nihilo (toutes ont déjà des sources). Effet purement additif. - [ ] Surveiller la première semaine après push : pas d'explosion d'interventions auto-créées - [ ] Vérifier qu'à la modification d'une machine, on voit bien `created` > 0 dans les logs PHP avec un type `maintenance_annuelle` quand la machine est éligible ### 3b. 14 machines LARIBOISIERE silencieuses **Commit** : `872be6f` (retrait fallback +3 ans) Avant le retrait du fallback, ces machines généraient 9 occurrences fantômes chacune sur 3 ans car le moteur faisait `today + 3 ans` quand le site n'avait pas de date de fin de contrat. Maintenant elles génèrent 0. - [ ] Vérifier que les 14 machines apparaissent dans l'onglet "Incohérence site" du bandeau - [ ] **Décision attendue** (cf section 5) avant de toucher quoi que ce soit ### 3c. Décalage local ↔ prod sur les en retard Audit comparaison BDD prod / local 2026-05-02 : **26 interventions en retard légitimes** existent en prod, n'existaient plus en local. Le commit `872be6f` initial supprimait ces en retard à la désactivation. Le commit `ba898d6` corrige : on les préserve désormais par défaut et on demande à l'admin via modal. - [ ] Si une machine prod avec en retard a été désactivée APRÈS le push de `872be6f` mais AVANT le push de `ba898d6`, ses en retard sont perdues. Vérifier les logs ou demander à Aurélien si une telle désactivation a eu lieu entre-temps. --- ## 4. Décisions / actions optionnelles à prendre ### 4a. Replanifier en batch les 12 machines éligibles à la 3ème série **Pour** : voir immédiatement la "Maintenance annuelle" sur le calendrier sans attendre que chaque machine soit modifiée. **Contre** : action volontaire en prod, requiert backup. Pas critique car effet additif sans perte. Si on le fait, équivalent du script local `/tmp/replan_all_local.php` mais avec credentials prod. ### 4b. Endpoint admin "Replanifier toutes les machines actives" Discuté plus tôt. Filet de sécurité pour les rares cas import / restore qui ne passent pas par l'API. Non urgent. ### 4c. Drop column `interventions.priorite` (Lot C feature priorité) **Commit** : `5151cff` a retiré tout le code mais a laissé la colonne. Si on veut nettoyer le schéma, faire une migration `DROP COLUMN priorite` (à coordonner avec la prod, pas urgent). --- ## 5. Questions en suspens (clarification Aurélien) ### 5a. ⛔ BLOQUANT chantier 4 — LARIBOISIERE **17 machines** sont cochées `sous_contrat_site=1` mais le site `sous_contrat=0`. Avant de coder le chantier 4 (cascade replanif au changement date_renouvellement_contrat site), il faut savoir si c'est : - **a) Erreur de saisie** → cocher le site sous contrat + saisir date de renouvellement, OU décocher la couverture sur les 17 machines - **b) Cas métier réel** (sous-traitance, contrat ponctuel par équipement) → **refonte modèle** : couverture contractuelle au niveau machine indépendante du site Si réponse = (b), le chantier 4 et la 3ème série maintenance annuelle devront être adaptés (le check `site.sous_contrat=1` n'est plus pertinent comme garde-fou). ### 5b. Marqueur "ancien CERFA déjà fait" pour les machines en cycle terminé Le bandeau d'alerte affiche maintenant la raison "Cycle terminé, prévoir renouvellement" pour les machines dont la prochaine occurrence dépasse la fin de contrat. Question : Aurélien veut-il un workflow auto pour proposer un nouveau contrat au client X mois avant cette limite (action commerciale) ? Si oui, c'est un nouveau chantier (notification mail + dashboard commercial). --- ## 6. Chantiers déjà documentés mais non démarrés | Plan markdown | Sujet | Priorité | |---|---|---| | `/home/taaazzz/projects/CHANTIER_MACHINES_EXPIRATION_CONTRAT_SITE.md` | Modal alerte expiration contrat site | Moyenne | | `/home/taaazzz/projects/CHANTIER_PLANIFICATION_AUDIT_4_CHANTIERS.md` (chantier 4) | Cascade replanif site → machines | Bloquée par 5a | | Memory `project_chantier_rappels_habilitations.md` | Rappels mail habilitations techniciens | À planifier (deadline 2026-04-16 dépassée) | | Memory `project_retention_logs_cnil.md` | Plan retention logs CNIL | Long terme | --- ## 7. Tests / régressions à valider après push prod - [ ] PHPUnit pipeline GitLab vert (3702 tests) - [ ] Smoke test page admin/machines : bandeau silencieuses s'affiche - [ ] Smoke test logout : modal stylée - [ ] Smoke test désactivation machine : modal de choix (avec en retard) ou simple (sans en retard) - [ ] Smoke test calendrier interventions : pas de référence priorité résiduelle - [ ] Surveillance logs PHP container coolcare prod sur 24h pour détecter erreurs JS / PHP nouvelles --- ## Notes finales - **Aucun rollback prévu** : tous les commits sont compatibles vers l'avant. Si problème, le revert d'un commit demandera de revenir aussi sur les commits suivants qui en dépendent. - **Pipeline CI/CD** : le push déclenche un build kaniko + déploiement SSH. Vérifier le statut dans GitLab self-hosted (`http://192.168.1.153/Taaazzz-prog/coolcare_app/-/pipelines`). - **Container prod** : `coolcare_coolcare.1.kr0urgyn7wzd76c76vt0cktat` → sera remplacé par un nouveau container après le déploiement.