Contexte développement

# Contexte développement — Tech AWM 1.10.18


---

## CHANGELOG.md

## 1.10.18 — 2026-10-12 — Elementor depuis WordPress administrateur sans mot de passe

- Correction du démarrage Elementor via la session WordPress complète : chargement des capacités à `wp_loaded`, avant les menus, y compris sur `post.php?action=elementor`; aucune extension des droits des anciennes sessions limitées à une page.
- Supprime la mauvaise exigence de correspondance avec l'URL d'une seule page pour un administrateur WordPress temporaire : `edit_post` de WordPress décide pour chaque document.
- Corrige le conflit d'origines `couture-electro.com` / `www.couture-electro.com` : code de passage unique (90 secondes maximum) lié au compte temporaire, à la session, à la page et à l'hôte canonique; WordPress recrée ses propres cookies sur cet hôte, sans cookie d'authentification admin partagé.
- Quand la session temporaire fonctionne sur l'hôte canonique, les URLs admin et AJAX produites dans WordPress restent sur le même hôte. Seuls les couples HTTPS apex / www strictement identiques sont acceptés; les autres origines ne sont pas redirigées.
- Dans l'éditeur Elementor administrateur, la fenêtre Tech n'est créée qu'après un aperçu effectivement chargé. Les anciennes sessions Elementor limitées conservent leur comportement.
- Audit de passage et de préparation de l'éditeur (identifiants techniques seulement); aucun jeton, mot de passe ou contenu de page enregistré. Pas de modification d'Elementor ni des contenus clients.
- 25 assertions simulées incluant droits précoces, contrôle des origines, code unique, refus de rejeu, expiration et distinction session limitée/administrateur. Test de bout en bout sur vrai WordPress et diagnostic d'extensions tierces encore nécessaires.

## 1.10.17 — 2026-10-12 — Journal des interventions durable et interface wp-admin

- La fenêtre flottante Tech n'est plus affichée sur les pages classiques `/wp-admin/` : l'accès administrateur temporaire sans mot de passe reste identique. L'éditeur Elementor et le frontend conservent leur interface d'intervention.
- Toute modification WordPress reconnue par les hooks Tech AWM est écrite immédiatement dans une nouvelle table locale dédiée `{$prefix}awm_tech_audit_spool` avec `event_id`, `session_id`, nature, objet et horodatage UTC; aucun mot de passe, token, cookie ni contenu client n'est persisté.
- Remplace l'ancienne file `wp_options` limitée à 500 événements par une file SQL sans éviction silencieuse. Migration des événements historiques non envoyés, sans suppression avant confirmation. Copie de secours si la base locale n'est pas accessible.
- Envoi par petits lots (25) vers Core AWM avec accusé de réception, déduplication sur identifiant d'événement et séparation stricte des sessions. Un événement ancien non transmis n'est jamais attribué au nouveau technicien.
- Tech AWM central > Journal : chronologie des ouvertures, refus et modifications WordPress reçues; recherche par client, site, technicien, action ou objet, avec pages de 40. Une simple requête est identifiée comme observation, jamais comme modification confirmée.
- Les événements livrés restent dans la file locale 365 jours; les événements en attente ne sont pas purgés automatiquement. Les logs Core respectent leur politique de rétention propre.
- Limites : les actions WordPress qui ne déclenchent aucun hook peuvent ne pas être recensées; la désactivation du plugin ou l'intervention directe sur fichiers/SQL empêche un audit exhaustif. Les données d'une ancienne session expirée restent localement en attente si leur envoi a échoué; leur réconciliation sécurisée reste à développer.
- Validation locale PHP des files, de la migration et du journal de consultation. La validation sur un WordPress client et l'affichage public de la roadmap restent à confirmer.

## 1.10.16 — 2026-10-12 — SSO wp-admin : restauration des capacités avant les menus

- Cause de la page « Sorry, you are not allowed to access this page » : les capacités temporaires du compte Tech étaient restaurées à `admin_init`, **après** le chargement de `wp-admin/menu.php`. WordPress pouvait déjà avoir mémorisé les menus comme interdits pour le rôle de base lecture seule.
- Le contrôle central de session se déclenche maintenant à `wp_loaded` (priorité 0, après le boot du module à `init` et **avant** les menus), avec un repli `admin_init` sans double validation. Aucun droit `administrator` n'est stocké durablement.
- En cas d'absence d'autorisation, le compte reste en lecture seule et la connexion est refusée; la révocation ferme la session et son cookie. Des diagnostics expurgés (`admin_page_denied`, `admin_session_capabilities`) sont consignés localement.
- Séparation des identités WordPress temporaires `frontend/elementor` et `wp_admin`; les nouveaux comptes admin conservent un rôle permanent minimal. Une ancienne identité reprise est ramenée au rôle lecture seule lors du passage admin.
- Vérification des capacités `manage_options` et `activate_plugins` avant la redirection; message explicite à la place d'une fausse réussite silencieuse.
- Tests simulés : 18 assertions de contrôle précoce, expiration, révocation, séparation des privilèges et audit; syntaxe PHP, JS, JSON et ZIP à contrôler lors de l'emballage.
- À confirmer sur un **vrai WordPress** : bouton Monitoring → WordPress, administration des extensions, journal d'audit, navigation entre plusieurs pages et éventuelles extensions de sécurité.
- L'édition Unicode de la 4.5.391, SSL/DNS, Recovery, Autopilote, CRM, CallTracker/CPL et les autres modules ne sont pas modifiés. La restauration de la page couture-electro.com demande toujours une révision saine vérifiée.

## 1.10.15 — 2026-10-12 — Sélection strictement ciblée + verrou Hub Client Unicode
- `replace_text` requiert un `element_id` explicite ; plus aucune substitution globale dans toute la page. Recherche uniquement dans les vrais champs de contenu éditables, un seul champ cible.
- La sélection d'une section fournit au modèle ses widgets enfants ; au moment d'appliquer, le serveur recalcule les IDs réellement descendants du conteneur sélectionné et refuse toute action externe.
- Limite de trois widgets concernés par une même action ciblée ; rejette les modifications non ciblées du titre, l'ajout global de section ou les CSS globaux.
- Le navigateur transmet la sélection au serveur et affiche le nouveau texte proposé (aperçu borné) avant approbation.
- Refuse toute écriture de page si Hub Client est plus vieux que 1.14.20, sans bloquer l'accès normal aux diagnostics et à WordPress.
- Les permissions temporaires, l'audit, SSL/DNS, Autopilote, Recovery et le CPL ne changent pas.
- Restauration historique : les snapshots créés avant ce correctif peuvent être eux-mêmes altérés par l'ancien double unslash ; préférer une révision Elementor saine.

## 1.10.14 (2026-10-12) — permission admin héritée de Tech + ouverture non bloquante

- WordPress : administration complète est activée par défaut pour les clients CRM actifs avec Tech AWM actif. L'autorisation n'est effective que pour un site Connector autorisé et une intervention centrale valide. Les anciens booléens `false` provenant de l'ancienne case décochée ne sont pas interprétés comme refus manuel; un nouvel indicateur explicite de refus conserve toute désactivation demandée à partir de cette version.
- Dans les permissions Tech du client, désactiver volontairement la case enregistre le refus; la réactiver efface ce refus. Désactiver Tech ou le client CRM coupe immédiatement l'accès; le refus persiste après une réactivation de Tech.
- Monitoring : les formulaires ouvrant un nouvel onglet sont désormais soumis SYNCHRONEMENT pendant le clic, sans animation bloquante sur la page centrale (corrige le blocage des fenêtres contextuelles dû au `setTimeout`).
- Intervention sur la même page : chargement arrêté après 20 secondes, état cliquable restauré et erreur utile. Les vérifications de permission et de version agent s'exécutent avant les préparations longues; l'accès WordPress ne déclenche plus un déploiement d'agent inattendu.
- Journal local, Core Security Log, connexion à usage unique, privilèges dynamiques, politiques CRM/Connector/site_id et contrôles HTTPS préservés. À tester sur un véritable site WordPress; aucune garantie d'audit des extensions tierces contournant les hooks.

## 1.10.13 (2026-10-11) — administration temporaire complète et audit

- Rétablit les deux raccourcis WordPress et Tech sur site dans Monitoring (cartes responsive).
- SSO WordPress sans mot de passe client via code de passage à usage unique, session liée au client/site/instance et HTTPS.
- Droits d’administration WordPress accordés uniquement pendant la session temporaire AWM validée; rôle de base lecture seule, aucun rôle administrateur persistant.
- Autorisation distincte explicite `wordpress_full_admin`, initialement désactivée (permissions CRM Tech).
- Journal local et central des changements contenus/Elementor/plugins/thèmes/utilisateurs/options et repli de traçage des requêtes tierces.
- File locale d’événements non synchronisés avec protection anti-attribution à un autre technicien; pas de PII ou secrets enregistrés.
- Contrôles HTTP/DNS, Autopilote, Recovery, CPL, protection de formulaires et autres modules préservés.

# Tech AWM 1.10.12 — 2026-10-11 — Monitoring unifié et alertes DNS avec preuve

- **Monitoring :** fusion des deux tableaux « Monitoring des sites » et « Certificats, DNS et santé WordPress » en une seule carte responsive par site géré (client CRM actif + Connector autorisé). Indicateurs de santé, SSL, DNS, WP-Cron, SQL, alertes, mises à jour et accès Fiche Tech réunis.
- **Recherche locale :** filtres par nom, domaine, zone DNS, serveurs NS et adresses A/AAAA/CNAME; états, pagination 12/24/48 sans défilement horizontal ni requête supplémentaire.
- **DNS lisibles :** découverte de la zone DNS via SOA (utile pour `www`), affichage NS réellement retournés (p. ex. `ns1.alliancewebmarketing.ca`) et destination A/AAAA/CNAME. Aucune identification de fournisseur inventée.
- **Avertissements DNS :** conservation des valeurs antérieures et nouvelles, confirmation par deux relevés concordants séparés d’au moins 30 minutes, file prioritaire pour recontrôler les changements en attente, journal d’audit et courriel aux seuls techniciens Tech configurés. Déduplication par zone et transition, sans alerte au premier relevé, sans email aux clients.
- **Compatibilité :** ancien schéma DNS 1.10.11 rebasé silencieusement lors de la première mesure version 2; aucune fausse alerte liée à l'ajout des NS de zone. Alertes configurables dans Tech → Réglages → Notifications et escalade, activées par défaut pour les destinataires techniques.
- **Sécurité :** lecture seule, validation des noms hôtes et adresses publiques pour SSL, permission/nonce existants, clients CRM actifs et Connectors autorisés. Historique conservé pour audit; pas de modification DNS, pas de données SQL client envoyées par courriel.
- **Tests locaux :** harnais PHP sur vraies classes Tech (NS/zone, changements, migration, courriels, doublons, client inactif, rendu), lint PHP/JS et intégrité ZIP. Vérification visuelle sur le WordPress réel et livraison effective des courriels SMTP encore à confirmer.
- **Inchangé :** modules Core, Hub, Hub Client, CRM, CallTracker/CPL, Stats, Studio, Soutien, Assistant et Recovery; sondes HTTP, Autopilote et interventions client inchangés.

# Tech AWM 1.10.11 — Diagnostics SSL, DNS, WP-Cron et SQL — 2026-10-11

- **Fonctionnel, phase 1 :** certificat HTTPS et dates d expiration, empreinte de changement DNS, retard WP-Cron et poids des options WordPress autoload / statistiques des tables SQL.
- **Source de vérité :** seuls les WordPress connectés/autorises de clients CRM actifs et actives pour Tech. Sites externes admissibles si Connector autorise.
- **Securite :** SSL/DNS en lecture seule depuis Alliance (public IP uniquement, sans acces aux IP privees); WP-Cron/SQL en lecture seule sur le site et synthese expurgee envoyee au canal Connector existant. Aucun mot de passe, contenu SQL, argument de tache ni changement de DNS n est collecte.
- **Alertes :** dates SSL 30/14/7 jours, changements DNS apres confirmation, erreurs TLS transitoires recontrolees sur deux passages distants d au moins 15 minutes. Pas de courriel CRITICAL direct.
- **UX :** tableau lisible clair/sombre et responsive dans Monitoring avec controle manuel SSL/DNS par site; resume dans la fiche Tech. Mesures anciennes/absentes = En attente/A verifier, jamais OK invente.
- **Compatibilite :** source Suite 4.5.386; autres composants byte-for-byte identiques. Les agents clients 1.10.10 restent fonctionnels, mais telemetrie WP-Cron/SQL disponible apres installation Tech 1.10.11 sur les sites.
- **Limites :** sans test sur vrai WordPress (production) et sans confirmation publique en ligne. Pas encore de scan DKIM (selector inconnu), diagnostic des hooks bloquants et SQL lent, ni test synthetique Elementor.
- **Documents :** README, CHANGELOG, ROADMAP, validation et journal de Suite synchronises.

# Tech AWM 1.10.10 — sites WordPress réellement gérés — 2026-10-11

- La page **Protection formulaires** inclut uniquement les sites appartenant à un client **actif dans CRM AWM** ET disposant d’un **Core Site Connector / Hub Client autorisé, non révoqué**. Un domaine conservé pour SEO, Ads, comptabilité ou un autre service ne suffit pas.
- Le lieu d’hébergement n’est jamais un critère : un WordPress externe connecté reste éligible. Un site déconnecté, jamais appairé ou révoqué est absent des listes et compteurs.
- Même filtrage pour propagation globale, synchronisation cron, Appliquer et Vérifier. Le droit du Connector est revérifié juste avant chaque requête distante.
- Aucune suppression : l’historique et les modes particuliers sont conservés jusqu’à une éventuelle reconnexion. Aucune modification de la logique Elementor, des courriels, de CallTracker, de la surveillance HTTP ni des sondes.
- Statut opérationnel CRM et Connectors Core existants réutilisés sans nouvelle table SQL ni logique d’hébergement présumée.
- Validation : tests PHP isolés, contrôle PHP/JS et ZIP; valider sur un site WordPress réel avant propagation massive.

# Tech AWM 1.10.9 — Respect du statut actif CRM dans Protection formulaires — 2026-10-11

- Liste, métriques et propagation anti-spam limitées aux clients opérationnels selon CRM AWM (non-actifs, archivés et supprimés exclus).
- Validation du statut au moment de l'appel distant et avant la vérification manuelle, même après une modification de statut concurrente.
- Le cron ignore les entrées historiques inactives lors du calcul du prochain réveil, sans les supprimer : restauration possible après réactivation.
- États vides et libellés actualisés pour afficher uniquement les sites des clients actifs.
- 17 tests de contrat locaux réussis; PHP lint, checksums ZIP et manifest vérifiés. Aucun changement de schéma SQL.
- Comportement du Honeypot/Elementor, email client, LeadTracker, Tech monitoring, CSS, Core/Hub/CRM et 10 autres archives Suite inchangé.

# Tech AWM 1.10.8 — Protection formulaires : harmonisation UX / CSS — 2026-10-11

- Harmonisation de **Tech AWM → Protection formulaires** avec les surfaces, bordures, typographies et variables clair/sombre du shell AWM, sans styles codés en blanc.
- En-tête Tech / Sécurité, indicateurs lisibles, sections « Protection par défaut » et « Protection par site » avec instructions courtes.
- Liste compacte de 84+ sites au lieu de grandes cartes en deux colonnes, états explicites, version Hub Client, compteurs issus du dernier relevé, diagnostics d'erreur.
- Recherche client/domaine avec accents, filtres des états, pagination locale 15/30/60 et état vide informatif, sans appel AJAX supplémentaire.
- Boutons **Appliquer** et **Vérifier** restent distincts et liés au bon client_id/site_id et à leurs nonces; choix global et exception par site préservés.
- Retour à la ligne de travail après une action par site dans le même onglet grâce au stockage temporaire du filtre/page, sans ajouter le nom du client à l'URL.
- Responsive tablette/mobile sans défilement horizontal et sans texte illisible; meilleure accessibilité (labels, focus clavier, contrastes, préférence réduction des animations).
- Un garde-fou de compatibilité conserve **Tech 1.10.7** comme version minimale du runtime client : une mise à jour d’interface sur le Hub ne force pas la mise à niveau de 84 agents clients.
- **Aucun changement** aux règles anti-spam, à la validation Elementor, au routage des courriels/LeadTracker, à Hub Client, aux sondes HTTP, aux permissions, à Recovery ou au CPL.
- Tests locaux de rendu PHP sur 84 sites simulés et vérifications navigateur Chromium en modes sombre/clair, bureau/tablette/mobile. Validation en production WordPress et Elementor Pro à confirmer.

# 1.10.7 — 2026-10-11 — correctif alertes CRITICAL trompeuses
- Correctif de la double vérification immédiate : les probes rapprochées ne confirment plus une panne.
- Confirmation dans des passages WP-Cron distincts avec bornes 90–1800 s; au moins 3 contrôles/210 s pour les échecs sans HTTP.
- Retry planifié prioritaire pour anomalies récentes; capacité de rotation préservée pour les autres clients.
- GET avec limite de taille, délai 7 s et sans `Range` / `no-cache`; 403/429 classés en avertissement.
- Détails SMTP/alertes : code HTTP, erreur WP_Error/cURL, horodatages, durée, URL exacte, note de point de mesure unique.
- Fiche Tech et timeline : erreur technique et horodatage lisibles; pas de message « hors ligne » non confirmé.
- Dédoublonnage des courriels répétés 30 minutes pour l'incident HTTP, sans supprimer son journal.
- Aucun changement de schéma SQL, Hub Client, antispam Elementor, CPL ni moteur Recovery.
- Lint PHP + tests isolés : PASS. Tests sur le site euro-spa.com et WordPress réel : non effectués.

# 1.10.6 — 2026-10-11 — pilotage central Elementor Form Guard
- Nouveau menu Tech AWM > Protection formulaires, affichage réactif par site/client avec recherche.
- Mode global et exceptions locales au site, sauvegarde nonce + permission admin Hub.
- Déploiement en petites tranches via le canal Core/Hub Client existant, jamais via endpoint public ni accès WP admin du client.
- Réponse confirmée par client_id/site_id/instance_uuid + mode, et diagnostics explicites en cas d'échec.
- Télémétrie agrégée (passages, blocages, faux positifs à surveiller), sans PII.
- Découverte quotidienne des nouveaux sites et reprise non-bloquante des sites encore hors ligne.
- Aucune modification de Recovery, Autopilote ou des modules CallTracker/CPL.
- Tests isolés du pilotage et des identités : PASS; validation end-to-end sur WordPress réels requise.

# 1.10.5 — Tech systeme par defaut — 2026-10-01
- Tech est actif par defaut pour tout identifiant client valide; la resolution CRM temporairement indisponible ne vaut plus desactivation.
- Seule une action humaine enregistrant `_awm_thech_enabled=0` desactive Tech durablement.
- Compatible avec Core 4.5.262 qui installe, active et met Tech a niveau avant Recovery.

# 1.10.3 — canal autonome de réactivation Hub Client — 2026-09-28
- Ajoute `awm-tech-rescue/v1/hub-client/reactivate`, disponible sans runtime Hub Client.
- Authentification stricte par le secret de scan local chiffré déjà synchronisé avec Core.
- L action est limitée au plugin canonique `hub-client-awm/hub-client-awm.php`; aucun slug arbitraire n est accepté.
- Respecte le scope site/réseau mémorisé par la configuration de migration MU lorsque disponible.
- Journalise uniquement le résultat et les versions, jamais le secret.
- Cette route rétablit le canal de gestion; elle ne déploie aucune mise à jour et ne modifie pas les gardes Recovery.

# 1.10.2 — autopilote extensions observable et réveil immédiat — 2026-09-25
- Activer une politique `Automatique` déclenche maintenant un premier passage immédiat au lieu d attendre jusqu à une heure.
- Ajoute un watchdog et un état persistant : dernier passage, réussites, erreurs, blocages Recovery, inventaires rafraîchis et prochain passage.
- Le worker rafraîchit l inventaire WordPress avant d agir et conserve le `fleet_state` Recovery reçu du Hub Client.
- Un site sans `recovery_ready_for_auto` est compté `Bloqué Recovery`, pas comme une erreur opaque.
- Le profil Tech central conserve désormais `fleet_state` et `intervention_preflight` au lieu de les perdre pendant la sanitisation.
- Le correctif d authentification temporaire Elementor 1.10.1 est intégralement conservé.

# 1.10.1 — passage WordPress automatique pour intervention Tech — 2026-09-24
- Corrige le cas observé sur Canevas Rive-Sud où **Elementor avancé** validait le site, Hub Client/Tech et la session sécurisée, puis tombait sur `wp-login.php` faute de cookie WordPress.
- La préparation Elementor retourne maintenant un passage à usage unique via `wp-login.php`; Tech valide le handoff, le `site_id`/instance via la session Alliance et la page cible avant toute authentification locale.
- Si le navigateur n est pas déjà connecté au WordPress client, Tech crée un utilisateur temporaire à capacités d édition limitées, ouvre un cookie WordPress borné par l expiration de la session Tech puis redirige vers Elementor sans demander de mot de passe.
- Le compte temporaire possède un mot de passe aléatoire jamais exposé, est journalisé, expire avec la session et est supprimé automatiquement avec réattribution des éventuels médias/contenus à un administrateur réel.
- **Intervenir sur le frontend** bénéficie du même bootstrap si aucun utilisateur WordPress n est déjà connecté; les contrôles `client_id + site_id + instance_uuid + domaine + page + scope design` restent obligatoires.
- Compatibilité conservée avec le fallback Hub Client historique : si WordPress redirige encore un ancien `editor_url` vers la page de connexion, Tech sait récupérer le handoff depuis `redirect_to`.
- La refonte UX Mises à jour de 1.10.0 est conservée intégralement.

# 1.10.0 — centre de mises à jour guidé — 2026-09-24
- Refonte complète de **Tech AWM > Mises à jour** pour un usage stagiaire : trois espaces distincts **À faire maintenant / Installer / Avancé**.
- Les mises à jour sont regroupées par site avec un seul bouton principal **Mettre à jour ce site**, puis le détail des extensions en second niveau.
- Les sites sans mise à jour sont repliés pour réduire le bruit visuel.
- L'installation de nouveaux modules utilise un seul sélecteur global **Site de destination** au lieu d'un grand menu répété dans chaque carte.
- Les modules AWM et les extensions WordPress approuvées sont séparés et présentés dans des blocs progressifs.
- Les politiques automatiques, l'inventaire complet, les versions Suite et WordPress/thèmes passent dans une **Zone avancée** repliée.
- Ajout d'une navigation mémorisée, d'une cible d'installation mémorisée et d'un flux de mise à jour site par site avec revérification d'inventaire.
- Responsive revu pour éviter les grands menus et rendre les tableaux de détails lisibles sans imposer de barre horizontale dans le parcours principal.

# 1.9.4 — mises à jour tierces directes via Hub Client — 2026-09-23
- Supprime la dépendance implicite à `AWM_Core_Recovery_Library` pour lancer une mise à jour tierce.
- Tech appelle maintenant directement la route Hub Client `tech/plugin/update` avec `client_id + site_id + plugin_file + target_version + operation`.
- Les états `review_required`, `rolled_back` et échecs protégés sont remontés comme erreurs au lieu d être affichés comme succès.
- Les boutons indiquent **Mettre à jour protégé** et rappellent que les extensions premium utilisent la licence du site.

## 1.9.3 - Session glissante + réécriture texte déterministe - 2026-09-23
- La session d intervention se renouvelle de 20 minutes à chaque activité authentifiée, avec plafond dur de 4 heures depuis sa création.
- Le cookie HttpOnly local suit la nouvelle expiration afin que la navigation frontend ↔ Elementor ne tombe plus après 20 minutes d utilisation active.
- Les demandes rédactionnelles explicites sur un widget sélectionné utilisent un moteur déterministe : Tech choisit lui-même le champ Elementor puis demande uniquement la valeur finale au modèle.
- Les intentions SEO, reformuler, raccourcir, allonger, développer, simplifier, corriger, ton vendeur/professionnel et rédaction sont couvertes.

## 1.9.2 - REST same-site www/apex stable - 2026-09-23
- Corrige le cas ou l editeur WordPress est ouvert sur le domaine apex alors que `rest_url()` pointe vers l alias `www` (ou inversement).
- Le client Tech compare les hote canoniques; pour un alias `www`/apex du meme site, il conserve le chemin REST mais utilise l origine actuellement ouverte dans le navigateur.
- Les appels REST utilisent `credentials: include`, `X-WP-Nonce`, le jeton Alliance, la surface et l URL courante.
- Le panneau sante reutilise le meme transport authentifie; aucun second client REST non nonce ne subsiste.
- Les controles serveur `current_user_can(edit_post)`, session Alliance, site_id et instance_uuid restent inchanges.

## 1.9.1 - authentification REST persistante frontend / Elementor - 2026-09-23
- Corrige `awm_tech_target_forbidden` lors du passage d une session Frontend vers l editeur Elementor.
- Les appels REST de la fenetre Tech transmettent maintenant le nonce WordPress `wp_rest` en plus du jeton prive Alliance.
- WordPress conserve ainsi l utilisateur courant sur `/wp-json/` et `current_user_can('edit_post', ...)` reste verifiable au lieu de retomber sur l utilisateur 0.
- Le controle de permission n est pas assoupli : utilisateur connecte + droit d edition + session Alliance + site_id/instance_uuid restent obligatoires.
- Le moteur Elementor generalise de 1.9.0 est inchangé.

## 1.9.0 - moteur Elementor generalise - 2026-09-23
- Généralise l intervention ciblée aux widgets, containers, sections et colonnes.
- Ajoute un planner IA minimal basé sur les capabilities exactes de l élément sélectionné.
- Prend en charge les transformations texte naturelles, images directes/images de fond et réglages layout/style réversibles.
- Les widgets tiers restent fail-closed : seulement réglages universels sûrs, jamais de repeater/formulaire arbitraire.
- Toutes les écritures conservent SHA-256, snapshot et rollback.

## 1.8.6 - reecriture ciblee fiable et icone reglages visible - 2026-09-23
- Corrige le cas ou une demande redactionnelle sur un widget selectionne arrivait jusqu au modele mais terminait sans action exploitable.
- Ajoute un repli IA minimal specialise sur le seul champ texte du widget selectionne; l action finale reste `set_setting`, SHA-256 controlee, permissionnee et reversible par snapshot/rollback.
- Le repli est limite aux widgets `heading`, `text-editor` et `button` et ne s active que pour une intention redactionnelle explicite.
- L icone Reglages de la fenetre Frontend utilise maintenant une police symbole systeme explicite pour ne plus apparaitre vide avec la police terminale.
- Conserve les gardes remote_status/permissions de 1.8.5 et le diagnostic detaille de 1.8.4.

## 1.8.5 - restauration de la garde remote_status / permissions - 2026-09-23
- Corrige la régression `Call to undefined method AWM_Hub_Client_Tech_AWM::remote_status()` observée pendant une conversation Frontend.
- Restaure les deux gardes internes `remote_status()` et `has_permission()` qui existaient en 1.8.1 mais avaient été retirées accidentellement lors du refactor 1.8.2.
- `remote_status()` vérifie maintenant explicitement la disponibilité de `AWM_Hub_Client_Tech_Remote::status()`, intercepte toute exception et refuse les réponses non structurées au lieu de provoquer un fatal PHP.
- Les permissions `chat`, `file_uploads`, `elementor_write` et actions WordPress sûres repassent toutes par la même garde distante fail-closed.
- Aucun changement au format de session, à atomic_v3, Recovery, Core ou à l autopilote.

## 1.8.4 - Contexte widget cible et diagnostic exception par etape - 2026-09-23
- Lorsqu un widget Elementor est selectionne, Tech lit directement ce widget dans `_elementor_data` au lieu de reconstruire toute la page via le moteur Studio avant chaque conversation.
- Le contexte chat selectionne contient uniquement le widget cible, ses champs editables, le hash SHA-256 du document et le contexte minimal du site.
- Si la lecture ciblee echoue proprement, Tech peut encore replier vers le contexte Studio historique sans perdre la session.
- Le pipeline chat est maintenant balise par etapes (`remote_status`, `selected_context`, `payload_encode`, `remote_chat`, etc.) et toute exception journalise et affiche l etape, la classe PHP et le message exploitable.
- Le bouton Diagnostic affiche maintenant la derniere erreur Tech et son contexte plutot qu un simple resume WordPress/PHP.
- Aucune modification du moteur atomic_v3, de Recovery, des permissions ou de l autopilote.

## 1.8.3 - Fenetre Frontend fermee proprement et chat cible compacte - 2026-09-23
- Le bouton X masque desormais le panneau de facon deterministe et ne laisse qu un petit lanceur Tech AWM; les doublons de panneau sont elimines au bootstrap.
- Le CSS force explicitement le panneau ferme a `display:none`, meme apres deplacement ou rejeu des hooks Elementor/theme.
- Lorsqu un element Elementor est selectionne, Tech transmet au chat uniquement le widget cible, ses champs editables et le contexte minimal de page au lieu de toute l arborescence/inventaire.
- Le contexte site retire l inventaire logiciel complet des requetes de conversation, reduisant tokens, taille HTTP et risque de timeout/WAF.
- Les erreurs REST/chat affichent maintenant le code reel et un message exploitable; les erreurs distantes et exceptions sont journalisees dans Tech.
- L appel IA verifie l encodage JSON et remonte le statut/code amont au lieu d une erreur generique.

## 1.8.2 - Navigation frontend persistante pendant une intervention connectée - 2026-09-23
- Une session lancée par **Elementor avancé** peut suivre l administrateur/technicien connecté sur les pages du même site sans perdre la fenêtre Tech.
- La page WordPress courante devient automatiquement la cible d inspection, chat, application et rollback lorsque l utilisateur connecté possède `edit_post` sur cette page.
- La validation distante est recalculée par URL canonique de page et reste liée à `client_id + site_id + instance_uuid`; aucune propagation à un autre site ou répertoire.
- Le frontend transmet explicitement sa surface et son URL courante aux routes privées Tech afin de distinguer navigation frontend et session Elementor stricte.
- Ajout du bouton **Fermer Tech AWM** et d un lanceur compact pour rouvrir la fenêtre sans terminer la session.
- Le `thread_id` de conversation est conservé dans `sessionStorage` pendant la navigation de la même session.
- Un utilisateur WordPress non connecté ou sans droit de modification ne reçoit jamais la fenêtre d intervention.

# Tech AWM 1.8.1 - intervention URL canonique stricte

## 1.8.1 — Elementor avancé / intervention site exact — 2026-09-23
- Corrige le refus `La page d intervention doit appartenir exactement au site jumele` lorsque le site jumelé et WordPress diffèrent uniquement par l alias `www` / domaine apex.
- Le contrôle reste lié à `client_id + site_id + instance_uuid`; aucun autre sous-domaine n est accepté.
- Le port doit rester identique et la cible doit être HTTPS.
- Pour une installation en sous-répertoire, toute page d intervention doit rester dans ce répertoire exact.
- Les chemins encodés contenant `..`, NUL ou séparateur inverse sont refusés avant comparaison.
- Aucun changement au moteur atomic_v3, aux permissions, à Recovery ou au catalogue de modules.

# Tech AWM 1.8.0 - Modules AWM et état Hub Client MU

## 1.8.0 — bibliothèque privée orchestrée par Core — 2026-09-22
- Ajoute le panneau **Modules AWM** dans Mises à jour pour installer ou mettre à jour un module privé sur un `site_id` précis.
- Le catalogue n est pas codé en dur dans Tech : il provient de `AWM_Core_Update_Manager::remote_module_catalog()` et donc de la publication Core active.
- Tech transmet seulement client/site/slug; Core impose la version, le paquet, le SHA-256, l autorisation et la signature.
- Une nouvelle lecture `tech/inventory` est lancée après le déploiement pour confirmer l état réel du site.
- Un module déjà à la version cible est signalé comme déjà à jour et n est pas remplacé inutilement.
- La liste Sites affiche **MU protégé** lorsque Hub Client remonte `must_use=1` avec loader valide.
- La bibliothèque WordPress.org existante reste séparée des modules privés AWM.

# Tech AWM 1.7.40 - Suite 4.5.250

## 1.7.40 — activation sandbox ultra-légère — 2026-09-22
- Pendant `activate_plugin()`, si `WP_SANDBOX_SCRAPING` est actif, Tech définit uniquement ses constantes, enregistre son hook d activation minimal puis retourne immédiatement.
- Aucun runtime client/central, filtre, shutdown handler ou classe Elementor n est enregistré dans cette requête d activation.
- Le chargement complet reprend uniquement dans la requête PHP suivante, après activation réussie.
- Ce correctif complète Hub Client 1.11.51 qui sépare installation et activation en deux requêtes.

# Tech AWM 1.7.39 - Suite 4.5.248

## 1.7.39 — bootstrap client résilient après mise à jour distante — 2026-09-22
- Corrige le pilote Allo Déménagement : Hub Client 1.11.50 s installe, mais la première requête après remplacement de Tech pouvait répondre par la page WordPress « erreur critique ».
- Le runtime client Tech n est plus chargé pendant `plugins_loaded`; il est démarré plus tard avec garde `Throwable` et classes anti-doublon.
- Les requêtes privées Hub Client `update/status`, `update/apply` et `update/rollback` restent volontairement légères : elles exposent la version Tech sans charger le runtime Elementor complet.
- Une erreur de bootstrap Tech est mémorisée localement sans chemin serveur absolu afin de protéger le site et faciliter le diagnostic suivant.
- Les fonctions Tech/Elementor restent chargées sur les requêtes normales, REST Tech, admin et frontend; aucune permission ni signature n est assouplie.
- L autopilote Recovery reste suspendu.

# Tech AWM 1.7.38 - Suite 4.5.243

## 1.7.38 — Accès au site manuel compatible Recovery suspendu — 2026-09-22
- Le clic administrateur **Accès au site** est maintenant traité comme une intervention manuelle explicite.
- Si Hub Client ou Tech doit être préparé avant l ouverture de la session, Tech appelle Core avec `manual=true` et le `site_id` exact.
- Le chemin manuel conserve canal signé, SHA-256, sauvegarde/rollback fichiers et vérification de version.
- L autopilote reste suspendu et aucun déploiement implicite ne contourne Recovery.
- Correction pertinente après migration d hébergement : une preuve RESTORE_TEST peut être invalide sur la nouvelle topologie, sans empêcher une intervention manuelle protégée.

# Tech AWM 1.7.37 - Suite 4.5.235

## 1.7.37 — Etat Recovery exploitable par le Tech — 2026-09-15
- Les cartes Recovery du parc distinguent route de secours, périmètre de sauvegarde et vrai test de restauration.
- `Recovery prêt` ne signifie plus que l'URL répond : l'interface montre explicitement si l'automatisation reste interdite.
- Aucun changement de privilège : un Tech AWM reste administrateur par défaut, avec restrictions explicites possibles.

Date : 2026-09-15

Boutons Recovery relies aux identites nominatives via Core, acces aux portes clientes deja verifiees meme si WordPress est maintenant indisponible. Moteur de mise a jour protege sur version cible exacte et suivi de resultats. Bibliotheque centrale accessible depuis Core.

Retention: version courante + cinq precedentes; sauvegardes completes: cinq. Pas de comptes generiques Tech 1/Responsable. Aucune migration destructive de donnees metier.

Candidate de stabilisation. Aucun deploiement effectue. Recette reelle WordPress + MySQL/MariaDB + PHP-FPM/OPcache + HTTPS et watchdog systeme obligatoire avant activation. Autopilote Suite AWM toujours suspendu. Les paquets des nouvelles mises a jour tierces proviennent encore du fournisseur WordPress de chaque site; leur telechargement unique depuis Alliance reste au roadmap.

## Historique

## 1.7.35 — Recovery AWM integre au poste Tech — 2026-09-14

- Bouton Recovery compact dans l en-tete Tech et nouveau sous-menu Recovery.
- Inventaire des portes Recovery du Hub central et des sites Hub Client a partir du dernier `fleet_state` valide.
- Bouton Recovery dans les cartes/fiches de site et la liste Sites lorsque l URL de secours a ete annoncee.
- Aucun mot de passe Recovery ni secret serveur n est stocke dans Tech; l authentification reste celle de la porte externe.
- UX niveau 1 documentee : dernier stable cible uniquement; points plus anciens et BD reserves au responsable.

## 1.7.34 — Morning Brief Health transversal — 2026-09-12

- Le Brief AWM affiche le score Health Suite /100 et ses raisons de vigilance tout en conservant incidents, SLA et priorités comme autorités opérationnelles.
- Le score Health est rafraîchi avec le snapshot du cockpit et reste strictement informatif.

## 1.7.33 — Pulse opérationnel transversal — 2026-09-12

- Expose au Core un pulse incidents ouverts / critiques afin d alimenter la santé système transversale.
- Le pulse est en lecture seule et ne remplace pas les préflights, actions recommandées ou preuves Tech.

# Tech AWM 1.7.32 — préflight intervention, tournée Tech et capacité

- **Livré** : la fiche Tech affiche un préflight avant intervention à partir des preuves runtime disponibles : Connector, permissions d écriture WordPress et comportement OPcache.
- **Livré** : un état inconnu reste explicitement **À vérifier**; Tech ne déduit jamais qu un site est prêt lorsqu une preuve manque.
- **Livré** : la fenêtre Incidents regroupe les incidents par **client + site** dans une tournée Tech suggérée, triée par score maximal puis incidents nouveaux, afin de réduire les changements de contexte.
- **Livré** : une vue **Capacité Tech** montre ouverts, nouveaux, sites concernés, plus ancien incident, SLA dépassés/à risque et score maximal par responsable, avec un bloc Non assigné distinct.
- **Sécurité** : aucune réaffectation ni action sensible n est automatique; le préflight n expose aucun chemin serveur, secret Connector ou clé API.
- **Gouvernance** : ROADMAP, CHANGELOG, notes et validation/logs sont synchronisés avec Suite AWM 4.5.229.

# Tech AWM 1.7.31 — priorisation opérationnelle et historique étendu

- **Livré** : chaque incident reçoit un score opérationnel transparent `impact × urgence × confiance`, normalisé sur 100, sans masquer la criticité brute.
- **Livré** : la fenêtre Incidents affiche le score, ses trois composantes et une file d actions recommandées contextuelles (prise en charge, fiche Tech, Sécurité, note, résolution après vérification).
- **Livré** : les incidents ouverts sont ordonnés par score opérationnel, puis criticité et récence afin que le Tech traite d abord les situations les plus importantes.
- **Livré** : la fiche Tech possède maintenant un historique basculable **24 h / 7 j** pour les sondes, incidents, actions, formulaires et mises à jour déjà journalisés, sans dupliquer le moteur Stats.
- **Gouvernance** : roadmap, changelog, notes et validation/logs restent obligatoires et synchronisés avec Suite AWM 4.5.228.

# Tech AWM 1.7.30 — accélération opérations et observabilité

- **Livré** : filtres Client et Site dans les fenêtres Priorités du parc et Incidents, en plus des filtres criticité/signal/workflow; les choix restent mémorisés pendant la session.
- **Livré** : les sites avec incident ouvert passent en priorité dans chaque lot de sondes, sans dépasser la limite globale de 12 sondes par cycle; le round-robin normal continue pour le reste du parc.
- **Livré** : Wordfence Intelligence conserve les 12 dernières tentatives de synchronisation sans secret, mémorise le dernier succès et classe la fraîcheur en Données fraîches / Cache acceptable / Données périmées / Jamais synchronisé.
- **Livré** : la page Sécurité affiche dernier succès, dernière tentative et historique de synchronisation avec statut HTTP utile.
- **Gouvernance** : roadmap, changelog, notes de livraison et validation sont synchronisés avec Suite AWM 4.5.227.

## Tech AWM 1.7.29 — diagnostic Wordfence V3 clair et non bloquant

- Le refus Wordfence Intelligence n ouvre plus une fenêtre globale bloquante : l état apparaît directement dans le panneau Sécurité et le reste de la page demeure utilisable.
- Un HTTP 401 est identifié explicitement comme **clé Wordfence Intelligence V3 refusée** et explique que la clé doit provenir de **Wordfence > Account > Integrations**, pas de la licence du plugin Wordfence installée sur un site.
- Le panneau propose **Retester maintenant**, **Configurer la clé** et **Wordfence Integrations** sans exposer le secret et sans distribuer la clé aux sites clients.
- Le KPI Journal gratuit distingue désormais **Actif**, **Clé refusée**, **À vérifier** et **À configurer** au lieu d afficher Actif dès qu un secret existe.
- Les erreurs 429, réseau ou réponse invalide restent non bloquantes et conservent le dernier diagnostic utile; aucun faux résultat de vulnérabilité n est inventé.
- Le bloc de diagnostic suit la typographie personnelle Tech et reste responsive.
- ROADMAP, CHANGELOG, notes de livraison et rapport de validation sont synchronisés avec la version.

## Tech AWM 1.7.28 — alertes actionnables, overlays lisibles et Moniteur personnalisable

- Toutes les annotations de **Priorités du parc** liées à un site sont maintenant entièrement cliquables, pas seulement les situations corrélées : cliquer n importe où sur une ligne ouvre la fiche Tech complète du site.
- La fiche ouverte depuis une alerte fournit le résumé technique existant et ses actions contextuelles : ouverture du site, détails techniques, contrôles, Connector, mises à jour ou autres actions déjà autorisées selon l état réel du site.
- Les lignes cliquables affichent un indice visuel et une indication **Cliquer pour le résumé complet et les actions**; les actions sensibles conservent leurs confirmations et permissions existantes.
- La **Typographie dashboard** personnelle s applique désormais aussi aux fenêtres Tech, notamment **Priorités du parc**, filtres, annotations, résumés, historiques, boutons d intervention et fiches site ouvertes en overlay.
- Le **Mode moniteur** utilise maintenant le même moteur de personnalisation de blocs que le dashboard : visibilité, ordre, drag & drop, grille 12 colonnes et largeurs 1/4, 1/3, 1/2, 2/3, 3/4 ou pleine largeur.
- La disposition du Moniteur est indépendante de celle du dashboard et reste enregistrée par `user_id`; un Tech peut donc construire un écran mural différent de son poste de travail.
- La **Typographie Moniteur** conserve la priorité en Mode moniteur, y compris lorsque les blocs sont redimensionnés ou déplacés.
- ROADMAP, CHANGELOG, notes et rapports de validation sont synchronisés avec cette livraison.

## Tech AWM 1.7.27 — édition de grille sans panneau superposé

- Quand le Tech choisit le préréglage **Personnalisée**, le panneau de personnalisation se ferme automatiquement afin de rendre tout le dashboard disponible pour le drag & drop.
- Un bouton **Déplacer les blocs** permet aussi d entrer directement dans ce mode lorsque la disposition enregistrée est déjà personnalisée.
- Pendant le déplacement, une barre compacte reste en bas de l écran avec **Annuler** et **Enregistrer mon tableau**; le panneau flottant ne masque plus la carte ni les autres blocs.
- Ouvrir de nouveau l icône Personnaliser met le déplacement en pause sans perdre la disposition de travail; fermer le panneau sans sauvegarder restaure les préférences enregistrées.
- Les raccourcis, blocs visibles, typographie, profils 1080p/4K, grille 12 colonnes et responsive interne restent sauvegardés par `user_id`.

## Tech AWM 1.7.26 — dropdown de liens, blocs container-responsive et typo des fiches

- `Liens personnalisés` devient un dropdown compact directement dans la zone d actions de l en-tete Tech, avant Personnaliser et Light/Dark; les raccourcis ne consomment plus de largeur en permanence.
- `Fermer` du panneau Personnaliser devient un vrai bouton compact avec icone, cohérent avec le reste du shell.
- La Carte utilise maintenant la largeur réelle de son bloc : les périodes se réorganisent en 4 puis 2 colonnes au lieu de déborder sur le bloc voisin.
- `État des sites` abandonne le défilement horizontal lorsque la colonne devient insuffisante : chaque ligne se transforme automatiquement en carte avec libellés, puis en pile verticale sur les petites zones.
- Les blocs étroits utilisent des container queries : la décision de passer en mode compact dépend de la largeur du bloc 1/4, 1/3, 1/2, etc., pas seulement de la largeur globale du navigateur.
- La **Typographie dashboard** personnelle suit maintenant aussi la fiche Tech, ses onglets, métriques, SEO, WordPress, sécurité, historique, boutons et cartes de sites; l échelle reste propre à chaque `user_id`.
- Les préférences par `user_id`, la grille 12 colonnes, les ratios, le drag & drop, les profils 1080p/4K et les données de monitoring restent inchangés.

## Tech AWM 1.7.25 — en-tete compact et dropdown Dark

- Les raccourcis personnels quittent la grande barre sous le shell et sont maintenant injectes directement dans l en-tete Tech, a cote du contexte du module.
- Le bouton Personnaliser devient une icone compacte placee immediatement a gauche du bouton Light/Dark; la rangee supplementaire du dashboard est supprimee.
- Les raccourcis restent propres a chaque `user_id`, defilent horizontalement si l espace devient trop etroit et ne forcent plus une carte pleine largeur en hauteur.
- Le dropdown Prereglage et tous les selects du panneau Personnaliser utilisent maintenant un schema de couleur natif coherent en Dark et Light; les options ne peuvent plus apparaitre blanc sur blanc.
- Aucun changement au moteur grille 12 colonnes, aux ratios, au drag & drop, aux donnees de monitoring ni aux Connectors.

## Tech AWM 1.7.24 — grille responsive personnalisable

- Le dashboard utilise maintenant une grille 12 colonnes avec ancrage automatique et largeurs 1/4, 1/3, 1/2, 2/3, 3/4 ou pleine largeur.
- Chaque Tech peut déplacer les blocs directement en mode Personnaliser; le drag & drop réordonne la grille sans positionnement libre au pixel près.
- Chaque bloc conserve sa largeur et son ordre par `user_id`; un Tech peut donc afficher Visites verticalement en 1/3 tandis qu un autre l affiche horizontalement en 3/4.
- Les blocs changent leur présentation interne selon leur largeur : Top sites peut s étaler sur deux colonnes, KPI se recompone, Timeline et Carte deviennent compactes lorsque leur zone est étroite.
- Pour les paires Carte/Visites et Timeline/Incidents, une largeur 3/4 ajuste automatiquement le compagnon à 1/4 (et 2/3 à 1/3) lorsque les deux blocs sont voisins, afin de remplir proprement la rangée.
- Le responsive protège la mise en page : ratios personnels conservés sur bureau/1080p/4K puis empilement automatique lorsque l écran devient trop étroit.
- La taille de typographie personnelle est appliquée aussi aux textes secondaires du dashboard afin d éviter les éléments qui restent minuscules.
- Un bouton Réinitialiser la grille restaure la disposition AWM standard 2/3 + 1/3.

## Tech AWM 1.7.23 — flotte, bibliothèque et dashboard personnel

- Gestion globale Automatique/Manuel des extensions tierces actives et bouton Tout mettre à jour avec confirmation succès/échecs.
- Boutons de mise à jour harmonisés au CSS des autres actions Tech.
- Bibliothèque AWM initiale d extensions WordPress.org approuvées, installables à distance sur un site Hub Client connecté.
- Dashboard personnalisable par utilisateur Tech : blocs visibles, raccourcis personnels, disposition Standard/Carte en premier/Sites en premier, taille de typo réglable finement, profil Moniteur Auto/1080p/4K et taille Moniteur.
- Préférences enregistrées par utilisateur via AJAX, sans rechargement de page.
- La roadmap publique reste obligatoire et synchronisée avec la publication Suite active.

# Tech AWM 1.7.22 — Économiseur Chromecast + actions AJAX

- Ajoute **Économiseur** dans la barre du Mode moniteur pour démarrer l écran de veille immédiatement.
- Corrige l activation automatique pendant un cast Chromecast : les petits événements `pointermove` parasites ne réinitialisent plus continuellement l inactivité.
- **Réveil sur critique** réagit maintenant à une nouvelle transition critique; un incident déjà critique n empêche plus l économiseur de démarrer.
- `Vérifier maintenant`, le diagnostic `À vérifier`, les mises à jour d extensions et l enregistrement du Mode moniteur utilisent AJAX lorsqu un contexte précis de site est disponible.
- Ajoute **Mettre à jour les X** pour exécuter séquentiellement les mises à jour WordPress tierces disponibles puis revérifier le site une seule fois.
- Les actions gardent leur fallback serveur classique quand un contexte AJAX sûr n est pas disponible.

- Le CSS premium du bloc Mode moniteur / économiseur est appliqué à tous les formulaires de la page Réglages Tech.
- Cartes, champs, listes déroulantes, aides et barres d action utilisent désormais le même contraste, la même densité et les mêmes hauteurs.
- Les boutons Enregistrer des autres sections reprennent la barre d action du Moniteur sans devenir sticky, afin d éviter des superpositions pendant le défilement.
- Responsive : les grilles de réglages passent proprement sur une colonne sous 900 px.

# Tech AWM 1.7.20 — statuts de fiche actionnables et actions alignées

- Dans les fiches techniques multi-sites, **À connecter** devient cliquable et mène directement au Connector exact du `site_id` dans la fiche CRM.
- **À vérifier** devient une action réelle : si le site est connecté, le clic relance immédiatement l inventaire et le diagnostic d indexation; sinon il mène au Connector requis.
- Après **Vérifier maintenant**, le retour se fait sur la fiche du site concerné plutôt qu en haut de la page.
- **Vérifier maintenant** et **Ouvrir le site** utilisent maintenant exactement la même hauteur, le même alignement vertical et une icône centrée.
- Aucun changement au moteur de sondes, aux données SEO, aux mises à jour tierces ou au canal signé Core.

# Tech AWM 1.7.19 — fiches multi-sites, vérification immédiate et Moniteur fiabilisé

- Chaque site CRM, principal ou secondaire, possède sa propre fiche technique avec URL complète exacte, `site_id`, état, indexation et inventaire WordPress.
- **Vérifier maintenant** force un contrôle WordPress frais : état, indexation et disponibilités de mises à jour.
- Une mise à jour tierce détectée peut être lancée immédiatement depuis la fiche avec le chemin sécurisé existant, sauvegarde et rollback; les modules AWM restent sur le canal Core.
- Le bouton **Enregistrer le Mode moniteur** utilise désormais une action admin dédiée, confirme la sauvegarde et revient directement au panneau Moniteur.
- Les listes/réglages Moniteur et les inventaires plugins gagnent contraste, espacements et typographie pour rester lisibles en Dark.

## 1.7.18 — 2026-09-12
- Mode moniteur épuré : masque le shell Tech, le titre Vue globale et les badges de contexte/surveillance pour maximiser les données utiles au cast.
- Typographie agrandie en Mode moniteur pour KPI, priorités, carte et Top sites afin de rester lisible à distance.
- Bouton Light/Dark déplacé dans la barre de la carte en Mode moniteur.
- Ajoute un économiseur d écran navigateur configurable (1/5/10/30 min, minimal/opérationnel/rotation, luminosité, plage nuit).
- L économiseur affiche heure/date et état opérationnel, dérive lentement pour limiter le marquage et réveille le dashboard automatiquement sur incident critique si configuré.

## 1.7.17 — 2026-09-11

- En-tête de carte compact : compteur visites, périodes et Mode moniteur sont regroupés sur une seule barre.
- Suppression de la légende explicative et des tuiles de sites au-dessus de la carte; Top sites aujourd’hui devient la légende visuelle opérationnelle.
- Mode moniteur déplacé dans la barre de carte pour un accès direct au plein écran/cast.
- Carte agrandie verticalement afin d’utiliser l’espace récupéré, avec repli responsive à 1500 / 1100 / 782 px.
- Aucun changement au moteur GeoIP, aux teintes client/site, aux popups, au graphique intégré ni au polling.

## 1.7.16 — 2026-09-11
- Refonte la fiche Tech en console opérationnelle avec hiérarchie visuelle claire et densité accrue.
- Ajoute un en-tête compact avec rôle Principal/Secondaire, URL cliquable, score, disponibilité, indexation et actions principales.
- Ajoute une barre Santé du site sur une ligne : disponibilité, HTTP, indexation, vulnérabilités, mises à jour, versions Hub/Tech et dernier contact.
- Ajoute une zone **À faire** qui remonte seulement les anomalies/action recommandées; si aucun signal n exige d action, la fiche affiche un état calme.
- Ajoute les onglets **Vue d’ensemble / SEO / WordPress / Sécurité / Historique** afin d éviter une longue fiche technique verticale.
- La Vue d’ensemble présente trois cartes compactes : Santé technique, SEO essentiel et WordPress & maintenance.
- L onglet WordPress conserve l inventaire complet et ajoute les filtres Tous / À mettre à jour / Auto / Manuel / Inactifs.
- L onglet Sécurité résume alertes, vulnérabilités, criticité, transport et dernier contact; l Historique devient compact lorsqu il est vide.
- Renomme l action d accès complet en **Détails techniques** et évite de dupliquer un second footer d action dans le popup.
- Aucun changement de sonde, incident, Connector, données SEO, politique de mise à jour ou historique.

## 1.7.15 — 2026-09-11
- Renomme le Mode TV en **Mode moniteur** et l ouvre dans une fenêtre dédiée réutilisable, sans navigation WordPress, pour affichage plein écran/cast.
- Synchronise la couleur des rangs Top sites : numéro, nom et barre reprennent exactement la teinte du site sur la carte.
- Rend l URL complète cliquable dans le popup cartographique et dans la fiche Tech, avec ouverture dans un nouvel onglet.
- Enrichit la fiche Tech avec Index/No-index, source, HTTP final, URL finale, canonical, robots.txt, sitemap XML, directives robots et follow/nofollow.
- Ajoute la liste complète des extensions WordPress dans la fiche Tech avec version, état, mise à jour et politique Auto/Manuel/Canal AWM.

## 1.7.14 — 2026-09-11

- Transforme `Tech AWM → Mises à jour` en inventaire complet des extensions WordPress de tous les sites Hub Client connectés.
- Ajoute un choix `Manuel / Automatique` propre à chaque `client_id + site_id + plugin_file` et un bouton `Mettre à jour maintenant` pour les extensions tierces avec mise à jour disponible.
- L automatisation traite un nombre limité d extensions par passage horaire et ignore les clients CRM inactifs.
- Les modules AWM sont identifiés comme `Canal AWM` et ne peuvent jamais être mis à jour par le moteur générique WordPress.
- Ajoute dans la fiche Tech et la liste Sites un diagnostic `Indexable / No-index / À vérifier` fondé sur `blog_public`, `X-Robots-Tag`, la meta robots de l accueil et `robots.txt`, avec motif visible.
- La carte du Centre d opérations utilise une famille de couleur déterministe par client et une teinte différente pour chaque site du même client.
- La légende, les infobulles et popups indiquent `Principal / Secondaire` et l URL complète exacte du site, incluant sous-domaine et sous-dossier lorsqu ils existent.
- Les points de plusieurs sites partageant la même localité GeoIP sont légèrement séparés afin que leurs teintes restent visibles.

## 1.7.13 — 2026-09-11
- Compacte le Brief AWM du Centre d’opérations sur une seule ligne de résumé à largeur bureau : état, incidents, MTTD, prise en charge, MTTR, conformité, fenêtres 7/30/90 et accès aux priorités.
- Réduit fortement la hauteur des trois cartes de priorité : padding, badges, typographie et espacement sont resserrés sans supprimer le client, le site, la criticité ni le nombre de signaux.
- Supprime la grande zone vide au-dessus des cartes de priorité et remonte la carte GeoIP / activité temps réel dans le premier écran.
- Conserve un repli responsive : la ligne SLA peut passer sous le titre à largeur intermédiaire et les priorités reviennent en une colonne sur mobile.
- Aucun changement de données, sondes, incidents, SLA, GeoIP, Connector ou historique.

## 1.7.12 — 2026-09-11
- Corrige la régression du Centre d’opérations qui empêchait l’initialisation de la carte Leaflet et de la courbe après l’ajout des fenêtres SLA 7/30/90.
- Cause corrigée : le helper numérique `num()` était appelé pendant l’initialisation SLA avant la création de la constante JavaScript correspondante, déclenchant une erreur de temporal dead zone et arrêtant `ops-dashboard.js`.
- `num()` devient une déclaration de fonction hoistée afin que l’ordre d’initialisation soit sûr sans modifier les calculs SLA existants.
- Aucun changement de données, GeoIP, sondes, incidents, SLA, Connector ou historique.
- Ajoute au protocole de validation un smoke test d’exécution du script du cockpit, en plus du simple contrôle de syntaxe JavaScript.

## 1.7.11 — 2026-09-11
- Ajoute les objectifs SLA globaux MTTD / prise en charge / MTTR dans Réglages Tech; `0` signifie explicitement qu aucune cible n est définie.
- Ajoute des surcharges SLA par client puis par `site_id` depuis la fiche CRM → Tech, avec héritage déterministe `site → client → global`.
- Ajoute les fenêtres SLA 7 / 30 / 90 jours dans le Brief AWM, conservées côté navigateur pendant la session.
- Calcule la conformité uniquement sur les incidents possédant une cible explicitement configurée; aucune cible contractuelle n est inventée.
- Ajoute un état SLA par site : `Respecté`, `À risque`, `Dépassé`, `Échantillons insuffisants` ou `Objectif non défini`.
- `À risque` correspond à une moyenne entre 80 % et 100 % de la cible; `Dépassé` signifie une moyenne au-delà de la cible.
- Prépare le raccord futur CRM service/contrat avec le filtre `awm_thech_sla_targets`, sans migration DB ni modification destructive.
- Ajoute une escalade courriel optionnelle pour les incidents `error/critical` qui restent `Nouveau` et non pris en charge après un délai configurable de 5 à 1 440 minutes.
- L escalade est désactivée par défaut, possède ses propres destinataires, ne s envoie qu une fois par incident et journalise `email_escalated` uniquement après un `wp_mail()` réussi.
- Les clients CRM inactifs, incidents résolus ou incidents déjà pris en charge sont exclus automatiquement de l escalade.

## 1.7.10 — 2026-09-11
- Tech AWM consomme le statut canonique CRM : un client inactif disparaît du Centre d'opérations, des sites, du monitoring, de la carte, des priorités et des nouvelles alertes.
- Les sondes cessent pour les clients inactifs; les incidents encore ouverts sont fermés proprement avec un événement système `client_deactivated`, sans suppression d'historique.
- La réactivation CRM reprend automatiquement la surveillance avec les mêmes sites et le même Connector.
- Re-sondage prioritaire immédiat lors d'un premier signal `warning/error` afin de confirmer rapidement l'anomalie.
- Instrumentation MTTD réelle via `first_signal_at`; aucune valeur n'est fabriquée si le premier signal fiable manque.
- SLA 30 jours calculés globalement et par site (MTTD, prise en charge, MTTR).
- Notifications courriel configurables aux techniciens lors de la création d'un incident `error/critical`.

## 1.7.9 — filtres opérationnels et SLA Alliance v1

- Ajoute des filtres rapides dans le popup **Incidents** : état `Nouveau / Pris en charge`, responsabilité `À moi / Non assigné` et criticité `Critique / Erreur / Surveillance`.
- Ajoute des filtres rapides dans le popup **Priorités** : criticité et type de signal `Incident / 404 / Mise à jour / Surveillance`.
- Les filtres restent entièrement côté cockpit : aucune donnée brute n est supprimée et le polling silencieux continue d actualiser la source complète.
- Ajoute un résumé **SLA Alliance · 30 jours** directement dans le Brief AWM, sans créer un nouveau gros bloc vertical.
- Expose le délai moyen de prise en charge, le MTTR moyen, le taux de prise en charge et le nombre d incidents observés sur 30 jours.
- N invente pas de MTTD : tant que l horodatage fiable du premier signal avant confirmation n est pas instrumenté, l indicateur reste explicitement non disponible.
- Aucune migration DB : Tech conserve la DB 1.2.0 et calcule ces mesures à partir des incidents existants.

## 1.7.8 — prise en charge opérationnelle des incidents

- Ajoute le workflow humain `Nouveau → Pris en charge → Résolu` sans casser le statut technique ouvert/résolu utilisé par le moteur automatique.
- Ajoute un responsable Alliance, la date de prise en charge, la durée depuis détection, le temps avant prise en charge et la durée totale de résolution.
- Ajoute des notes internes et un historique append-only par incident avec acteur, horodatage et type d action.
- Le bouton `Prendre en charge` assigne automatiquement l incident à l utilisateur Alliance courant; un incident déjà assigné peut être repris explicitement.
- La résolution manuelle accepte une note et conserve l auteur; si le signal technique reste actif au prochain contrôle, Tech ouvre de nouveau un incident plutôt que de masquer artificiellement une panne réelle.
- Les résolutions automatiques du moteur sont aussi journalisées afin de distinguer clairement intervention humaine et retour à la normale détecté automatiquement.
- La Timeline universelle v1 affiche désormais les prises en charge et notes d incident en plus des ouvertures/résolutions.
- DB Tech passe de 1.1.0 à 1.2.0 avec champs de workflow et table `incident_events`; aucune donnée d incident historique n est supprimée.

## 1.7.7 — en-tête compact fusionné au shell AWM

- Supprime le deuxième bandeau `Centre technique Alliance / Tech AWM / Session réservée`.
- Remonte ces informations directement dans l en-tête principal Tech AWM via le slot sécurisé du shell Core 4.5.179.
- Libère de la hauteur avant les priorités et la carte sans retirer l information de sécurité ni la version.

## 1.7.6 — cockpit compact et densité opérationnelle

- Réduit fortement la hauteur utilisée par l’en-tête, l’état global, la surveillance et le mode TV.
- Conserve les six cartes Priorités / Incidents / 404 / Mises à jour / Formulaires / À surveiller sur une seule ligne lorsque l’écran le permet.
- Retire le microtexte répétitif des cartes sans retirer leur comportement cliquable ni leurs popups.
- Transforme le Brief AWM en bande compacte et conserve les trois situations principales.
- Réduit les espacements d’en-têtes de cartes et des contrôles de période afin de faire remonter la carte et les listes live.
- Conserve l’adaptation responsive : 6 → 3 → 2 → 1 colonne selon la largeur.
- Aucun changement de données, incident, GeoIP, sécurité, Connector ou base de données.

# Changelog Tech AWM

## 1.7.5 — Timeline universelle v1
- Ajoute la timeline opérationnelle des dernières 24 h au Centre d’opérations.
- Aligne incidents ouverts/résolus, sondes anormales, actions Tech, formulaires Stats et mises à jour détectées.
- Ajoute les filtres Tout / Incidents / Tech / Stats / Sondes / Mises à jour.
- Ajoute la chronologie récente à chaque popup de site.
- Conserve `client_id + site_id` et n’invente aucune causalité entre événements.
- Réutilise les tables Tech/Stats existantes; aucune migration DB.
- Conserve le polling silencieux et la carte Leaflet sans flicker.

# 1.7.4 — Brief AWM et corrélation d’incidents v1

- Regroupe les signaux actifs d’un même `client_id + site_id` dans une seule situation prioritaire afin d’éviter les doublons entre incident, 404, mise à jour importante et état à surveiller.
- Conserve toutes les vues brutes séparées : Incidents, 404, Mises à jour et Sites à surveiller restent consultables individuellement.
- Le regroupement ne déduit aucune cause : le popup indique explicitement que plusieurs signaux sont présents sur le même site sans conclure automatiquement à une causalité.
- Trie les situations par sévérité, nombre de signaux puis activité du site afin de faire remonter les cas les plus importants.
- Ajoute un **Brief AWM** sous les cartes d’attention avec état global, résumé du parc et trois situations prioritaires cliquables.
- Le Brief AWM se met à jour avec le polling silencieux existant sans reconstruire la carte ni provoquer de flicker.
- Ajoute au Futur officiel : timeline universelle du site, centre de mises à jour intelligentes, réparation semi-automatique avec snapshot/rollback, SLA/MTTD/MTTR, écran TV client intelligent, Health prescriptif, attribution jusqu’au revenu et couches cartographiques Visiteurs/Clients/Incidents/Formulaires/Revenus/Opportunités.

# 1.7.3 — priorités cliquables et activité live par site

- Remplace les KPI généraux du haut par six cartes opérationnelles cliquables : Priorités, Incidents ouverts, Erreurs 404, Mises à jour importantes, Formulaires aujourd’hui et Sites à surveiller.
- Chaque carte ouvre un popup alimenté par le dernier snapshot du Centre d’opérations; le contenu reste synchronisé pendant le polling silencieux.
- Les erreurs 404 correspondent uniquement aux points réellement sondés par Tech qui retournent HTTP 404; aucune 404 n’est inventée à partir du trafic Stats.
- Les mises à jour importantes regroupent les sites qui remontent des mises à jour WordPress/plugins/thèmes, avec priorité renforcée lorsqu’une mise à jour du core WordPress est disponible.
- Remplace le panneau Incidents à droite de la carte par une vue Temps réel avec Top sites aujourd’hui et liste des sites visités maintenant.
- Le Top sites est classé par pages vues du jour; la liste live est classée par visiteurs actifs puis pages vues.
- Chaque site de la liste live ou du Top ouvre la fiche Tech existante; aucune identité visiteur n’est exposée.
- Incidents résolus, tableau complet du parc, carte GeoIP et courbe transparente restent disponibles sous la vue principale.

# 1.7.2 — carte globale temporelle et graphique fondu

- La carte du Centre d'opérations reprend les périodes : À l'instant, 1 minute, 1 heure, 1 journée, 1 mois, 3 mois et 1 an.
- Tech consomme le nouveau contrat global read-only de Stats AWM 1.8.6; aucune logique GeoIP n'est dupliquée.
- La courbe des visites est maintenant dessinée directement par-dessus la carte avec fond transparent, comme la maquette validée.
- Un changement de période recharge uniquement les données nécessaires; le zoom est recalculé au changement manuel mais reste stable pendant le polling silencieux.
- À l'instant se rafraîchit plus rapidement sans reconstruire Leaflet; les autres périodes conservent un polling silencieux.

# 1.7.1 — clients identifiables sur la carte globale

- Reprend la logique visuelle de carte validée dans Stats AWM : noyau lumineux + halo GeoIP.
- Conserve `client_id + site_id` dans les points de présence Stats afin que le Centre d’opérations sache quel client/site génère chaque activité.
- Regroupe les points qui partagent la même localité et affiche tous les clients/sites concernés dans un popup détaillé.
- Le popup indique client, site, visiteurs actifs et état HTTP sans exposer de données d’un autre contexte hors de la vue Alliance.
- Ajoute le nombre de clients visibles sur la carte et une légende explicite.
- Le premier cadrage automatique n’est effectué qu’une fois; les mises à jour silencieuses ne déplacent plus la carte.
- Aucune nouvelle collecte GeoIP : Stats AWM 1.8.5 reste l’unique source des coordonnées/localités.

# 1.7.0 — Centre d’opérations AWM et incidents de parc
- Remplace le tableau d’ensemble principal par **Vue globale des sites**, un cockpit Alliance qui compile tous les clients et sites connus du registre CRM/Connector.
- Ajoute une sonde HTTP rotative côté Alliance : **12 sites par passage toutes les 2 minutes**, délai maximum de 4 secondes, redirections limitées et validation SSL active.
- Ajoute la base Tech **DB 1.1.0** avec historique des sondes et registre d’incidents; les sondes sont conservées 30 jours et les incidents résolus restent historisés.
- Ouvre un incident HTTP seulement après **deux échecs consécutifs** et un incident de lenteur après deux contrôles consécutifs à **2,5 s ou plus**, afin de réduire les faux positifs.
- Ajoute les incidents `http_unavailable`, `http_slow`, `connector_stale` et `security_alert`, avec résolution automatique lorsque le signal redevient sain.
- Agrège les données réelles Stats AWM disponibles : visiteurs actifs, pages vues du jour, formulaires, trafic horaire, métriques par site et points GeoIP réels sur la carte globale.
- Ajoute une carte Leaflet persistante, une courbe transparente, le classement automatique des sites en anomalie et une actualisation AJAX silencieuse toutes les 30 secondes sans reconstruction complète du dashboard.
- Ajoute un **état opérationnel AWM** (`Normal`, `À surveiller`, `Incident`, `Critique`) calculé à partir des incidents ouverts et un **mode TV** plein écran pour la supervision au bureau.
- Les lignes du parc remontent automatiquement selon la priorité lorsque leur état change; les incidents résolus se mettent aussi à jour sans rechargement complet.
- N’invente aucune donnée : les sites sans première sonde restent `En attente`, et la carte globale n’affiche que les localités GeoIP réellement présentes dans Stats.
- Ajoute **AWM Live Intervention** au futur officiel : le client pourra voir son propre site, le curseur du technicien et les changements appliqués sans voir Tech AWM, wp-admin, Elementor, les logs, prompts ou secrets.

# 1.6.9 — documentation de review publique et continuité roadmap
- Ajoute `ROADMAP.md` au paquet Tech afin que la roadmap publique puisse exposer un contexte de développement complet pour la version effective.
- Aligne README et CHANGELOG sur la version 1.6.9 pour faciliter la review avant tout développement parallèle.
- Aucun changement au runtime, aux Connectors, au `site_id`, à `instance_uuid`, aux secrets, au monitoring ou aux interventions.

# 1.6.8 — heure Alliance explicite et indépendante du fuseau WordPress
- Conserve les événements techniques en UTC mais affiche l administration centrale dans `America/Toronto`, avec changement automatique HNE/HAE.
- Ne dépend plus du fuseau global WordPress pour `Dernier contact` et les horodatages Tech centraux; une installation Alliance restée sur UTC n affiche donc plus quatre heures d avance.
- Réutilise l horloge Core centralisée lorsqu elle est disponible et garde un repli `America/Toronto` autonome dans Tech.
- Aucun changement aux Connectors, secrets, `site_id`, télémétries ou interventions multi-sites.

# 1.6.7 — monitoring Tech réellement par site_id
- Stocke chaque profil Tech dans le registre Connector du site exact (`tech_profile` + `tech_profile_synced_at`) au lieu d écraser les métadonnées globales du client.
- Isole versions WordPress/PHP/Elementor, inventaire, mises à jour, alertes, vulnérabilités et dernier contact pour le site principal, les sous-domaines et les installations en répertoire.
- Les actualisations manuelles et le monitoring de vulnérabilités utilisent désormais `client_id + site_id`; les empreintes critiques ne se mélangent plus entre plusieurs sites du même client.
- Les sessions d intervention sont liées à `client_id + site_id + instance_uuid` et refusent une page située hors du domaine/répertoire canonique du site.
- Le déploiement automatique d un runtime manquant reste limité au site principal tant que le déploiement distant site-scoped n est pas livré, afin d éviter tout déploiement sur le mauvais WordPress.
- La fiche Tech du client et le dashboard distinguent chaque site avec un popup et des actions uniques par `site_id`.

# 1.6.6 — parc client multi-sites
- Consomme `CallLink_CRM::canonical_client_sites()`.
- Liste Site principal et Sites secondaires séparément dans Tech.
- Affiche le rôle, le libellé, l’environnement et la source officielle du design.
- Marque explicitement les secondaires non associés au Connector comme `À connecter`.
- Empêche une intervention distante sur un secondaire non connecté au runtime Tech.
- Prépare l’association future de chaque runtime à un `site_id` précis sans créer de répertoire client parallèle.

# 1.6.5 — monitoring central automatique + inventaire à la demande
- Ajoute un scan central horaire côté Alliance qui réévalue les correspondances de vulnérabilités à partir des inventaires déjà reçus, sans installer de service payant.
- Journalise uniquement les nouvelles correspondances critiques afin de faire ressortir les changements importants sans bruit inutile.
- Ajoute « Actualiser les inventaires » dans le dashboard et la vue Mises à jour : Alliance peut interroger immédiatement les sites via le canal privé Hub Client au lieu d attendre leur prochain contact.
- Affiche la date du dernier scan automatique dans le dashboard et la section Sécurité.
- Conserve Wordfence Intelligence V3 comme source gratuite optionnelle et n ajoute aucune API de vulnérabilités payante.

# 1.6.4 — inventaire versions + journal gratuit des vulnérabilités
- Ajoute un inventaire détaillé WordPress, plugins et thèmes remonté par chaque runtime Tech : version installée, état actif et version de mise à jour proposée.
- Ajoute au dashboard Alliance la comparaison des versions de la Suite AWM avec la publication active.
- Ajoute le journal de vulnérabilités WordPress basé uniquement sur Wordfence Intelligence V3, documenté comme gratuit pour usage personnel et commercial.
- La clé Wordfence gratuite reste chiffrée côté Alliance; elle n est jamais envoyée aux sites clients.
- Compare les versions réellement installées aux plages affectées avant de signaler une vulnérabilité; les niveaux Critique/Élevé influencent le Health Score.
- Met en cache le flux central afin d éviter les appels répétés et n utilise aucune API de vulnérabilités payante.

# 1.6.3 — opacités séparées et choix de police
- Remplace l ancienne opacité totale par deux contrôles indépendants : opacité des fonds (0–100 %) et opacité du texte + bordures (25–100 %).
- Ajoute un choix de police appliqué en direct à toute la fenêtre Tech : Terminal moderne, Consolas, Courier New, Système premium, Arial ou Georgia.
- Conserve couleur terminale, presets Matrix / Bleu premium et réinitialisation; les préférences restent locales au navigateur Alliance.
- Migre automatiquement l ancienne préférence d opacité vers le nouveau réglage de fonds sans rendre le texte illisible.
- N altère ni la session Tech, ni les actions frontend, ni le chargement Elementor.

# 1.6.2 — couleurs fiables, réécriture de contenu et images IA
- Corrige le changement de couleur d un titre : les noms courants comme bleu, vert, or ou rouge sont normalisés vers des valeurs CSS sûres.
- Ajoute un repli CSS frontend limité à la page et réversible lorsque l élément sélectionné n expose pas d ID Elementor utilisable.
- Tech peut maintenant rallonger, condenser, corriger ou rendre plus formel/professionnel le texte sélectionné et proposer le texte complet comme action à appliquer.
- Ajoute une action de génération d image côté Alliance; l image est importée dans la médiathèque WordPress du site client et peut remplacer le widget image Elementor sélectionné.
- Les secrets IA restent chez Alliance; permissions, journalisation, snapshot/hash et rollback restent obligatoires pour les écritures.

# 1.6.1 — moteur d actions frontend
- Tech AWM privilégie maintenant l exécution plutôt que les instructions manuelles : une demande compatible doit produire une action réversible à appliquer.
- Ajoute les réglages design sécurisés pour couleur, taille de police responsive, alignement, marges, padding et fonds Elementor.
- Enrichit la sélection frontend avec les styles calculés de l élément ciblé afin de donner un contexte visuel concret à l IA.
- Affiche le plan d actions exact dans la fenêtre Tech avant « Appliquer maintenant ».
- Conserve snapshot, contrôle de hash Elementor, permissions Alliance, journalisation et rollback avant toute écriture.

# 1.6.0 — Dashboard Tech opérationnel + intervention frontend directe

- Fait du frontend du site client la surface d intervention principale; Elementor reste un mode avance distinct.
- Ajoute une session frontend Alliance temporaire qui conserve la fenêtre Tech pendant la navigation du site, sans exposer Tech aux visiteurs ordinaires.
- Ajoute la sélection visuelle directe des éléments Elementor depuis le frontend et conserve snapshot / appliquer / rollback côté serveur.
- Refonte le tableau de bord principal avec KPI réels, score de santé dérivé, priorités, sites surveillés et activité récente.
- Chaque carte, priorité et ligne du dashboard est cliquable et ouvre sa source dans une popup contextuelle; la navigation principale reste dans le menu WordPress à gauche.
- Ajoute les entrées WordPress : Tableau de bord, Sites, Monitoring, Alertes, Mises à jour, Sauvegardes, Sécurité, Rapports, Journal et Réglages.
- N invente aucune donnée de monitoring : les métriques absentes (sauvegardes, uptime historique, temps de réponse) restent explicitement marquées comme sondes à brancher.

# 1.5.18 — fenêtre persistante WordPress + Elementor et personnalisation

- Maintient la boîte Tech active pendant la navigation dans l administration WordPress tant que la session Alliance temporaire reste valide.
- Conserve la même session et la même page cible lors des passages WordPress ↔ Elementor; la sélection visuelle demeure réservée à Elementor.
- Ajoute un panneau Apparence dans la boîte : couleur terminale, code hexadécimal, opacité totale 25–100 %, presets Matrix / Bleu premium et réinitialisation.
- Les préférences sont appliquées en direct et conservées localement dans le navigateur du technicien, sans donnée client supplémentaire.
- Tech reste absent du Hub Client et du front-end public.

# 1.5.17 — isolation du preview Elementor et suppression de la boucle Safe Mode

- Corrige la cause du blocage **Loading / Enable Safe Mode** observé pendant une intervention Tech : le cookie de session Alliance était aussi lu dans l iframe `elementor-preview`.
- L iframe de prévisualisation Elementor est maintenant explicitement exclue du bootstrap front-end Tech avant toute validation, redirection ou création de handoff.
- Une session Tech conservée en cookie ne peut plus rediriger une page publique ordinaire vers `wp-admin`; seule une URL de lancement Tech explicite peut déclencher le parcours legacy.
- Le mode `editor_only` ne provoque plus de redirection à lui seul sur les requêtes front-end.
- Conserve la boîte terminal Matrix, le handoff serveur direct et les routes REST privées sans toucher au fonctionnement normal de la prévisualisation Elementor.

# 1.5.16 — Elementor Safe Boot + terminal Matrix

- Retarde complètement l initialisation JavaScript de la boîte Tech jusqu à ce qu Elementor ait réellement créé son interface et sa prévisualisation.
- Retire le MutationObserver global pendant le bootstrap Elementor et utilise un polling borné beaucoup plus léger.
- Empêche le double enqueue/localize lorsque les hooks WordPress et Elementor se déclenchent dans la même requête.
- N injecte plus le HTML de la boîte dans le footer avant que l éditeur soit prêt; la boîte est créée côté navigateur seulement après l initialisation Elementor.
- Nettoie le CSS terminal Matrix et applique une vraie police console, texte vert, fond noir/vert et accents lumineux à la boîte Tech.
- Si Elementor ne devient pas prêt dans les 30 secondes, Tech reste passif au lieu d ajouter de la charge au démarrage.

# 1.5.15 — Lancement Elementor fiable et visible

- Corrige le cas où un clic sur **Elementor** semblait ne rien faire pendant la préparation distante.
- Le clic affiche immédiatement un écran compact de progression avant l'appel serveur.
- Le POST vers `admin-post.php` est déclenché explicitement après le premier rendu visuel afin d'éviter qu'un script tiers neutralise le bouton.
- La préparation reste côté serveur, avec validation Hub Client / Tech, session Alliance signée et redirection uniquement vers le domaine jumelé.
- Aucun changement n'est apporté au chargement non intrusif de la boîte Tech dans Elementor introduit en 1.5.14.

# 1.5.14 — Terminal Matrix et chargement Elementor non intrusif

- Retire l injection directe des assets Tech dans `admin_head`, trop précoce pour certaines versions d Elementor et susceptible de perturber son démarrage.
- Les assets de la boîte Tech passent désormais uniquement par les files d enqueue et hooks de l éditeur Elementor, avec rendu de la boîte en fin d interface.
- Conserve une seule boîte de dialogue et aucun composant Tech sur le front public.
- Applique une esthétique terminale monospace vert Matrix à la saisie, aux messages et au diagnostic.
- Conserve le handoff Hub Client sécurisé et la session Alliance temporaire.

# 1.5.13 — handoff Hub Client et préflight live

- Tech central relit `update/status` juste avant une intervention afin de ne plus redéployer à cause d une télémétrie CRM périmée.
- Le préflight exige Hub Client 1.11.29+, Tech 1.5.13+ et la route privée de préparation réellement disponible.
- Dans Elementor, Tech accepte le handoff autonome créé par Hub Client et revalide silencieusement la session auprès d Alliance dans la nouvelle requête.
- Si la revalidation réseau échoue momentanément, la session déjà validée par Hub Client reste utilisable jusqu à son expiration.

# 1.5.12 — boot client resilient et contrat Hub Client

- Tech client se relance de facon idempotente sur `plugins_loaded`, `init` et `rest_api_init` afin de survivre aux remplacements a chaud du plugin.
- Le mode client depend maintenant de la presence de Hub Client, sans exiger qu une classe auxiliaire soit deja visible au moment exact du premier test.
- La route privee de preparation Elementor est desormais possedee par Hub Client 1.11.26; Tech conserve la logique de validation, resolution de page et creation du handoff.
- Le preflight Alliance exige Hub Client 1.11.26 ou plus recent.

# 1.5.11 — ouverture Elementor par handoff serveur direct

- Remplace le passage fragile front-end → `wp-admin` par une préparation serveur-à-serveur entre Core Alliance et l agent Hub Client du site.
- Le site résout la page cible, valide la session Alliance et retourne une URL Elementor contenant uniquement un handoff local à usage unique.
- Le handoff est consommé dans `admin_init`, puis supprimé; la boîte Tech est injectée dans `admin_head` avant le démarrage de l éditeur.
- Ajoute une route privée `awm-client-hub/v1/tech/intervention/prepare`, protégée par le secret de scan du site et la validation Connector de la session.
- Exige Hub Client 1.11.25 pour invalider OPcache après les mises à jour distantes et confirmer la version Tech réellement chargée, pas seulement la version du fichier.
- Si le runtime Tech ou le handoff ne sont pas réellement actifs, l ouverture Elementor s arrête avec une erreur explicite au lieu d ouvrir silencieusement sans boîte.

# 1.5.10 — continuité de session Elementor renforcée

- Corrige le transfert de session Tech entre le front du site et `wp-admin` lorsque le domaine bascule entre `www` et le domaine nu.
- Ajoute un handoff serveur temporaire et un cookie de domaine sécurisé pour restaurer la session dans Elementor même si les paramètres d URL sont retirés.
- Injecte les assets de la boîte Tech directement dans `admin_head` pendant une session valide, sans dépendre du footer Elementor ou de la file d enqueue WordPress.
- Affiche un diagnostic Tech explicite dans Elementor si une intervention a été demandée mais que la session ne peut pas être récupérée.
- Corrige les appels Connector d intervention pour transmettre le timeout avec la bonne signature.
- La boîte reste unique et réservée à Alliance; aucune surface Tech n est exposée au client.

# 1.5.9 — boîte Elementor injectée par les hooks natifs
- Corrige l absence de boîte Tech dans certaines versions récentes d Elementor : le runtime utilise maintenant les hooks officiels `elementor/editor/after_enqueue_scripts`, `elementor/editor/after_enqueue_styles` et `elementor/editor/footer`.
- Conserve `admin_enqueue_scripts` et `admin_footer` uniquement comme repli de compatibilité.
- Ajoute une deuxième sécurité côté JavaScript : si Elementor ne rend pas le HTML du footer attendu, la boîte unique est reconstruite depuis le markup de session localisé.
- Empêche les doublons lorsque le hook Elementor et le hook WordPress sont tous les deux exécutés.
- Tech reste invisible hors d une session Alliance valide et aucune palette n est ajoutée au front-end public.

# 1.5.8 — préparation Elementor automatique

- Le bouton d intervention ne bloque plus lorsque le site client possède une version Tech plus ancienne.
- Tech AWM utilise la publication active de Core pour installer ou mettre à jour automatiquement le runtime Tech requis avant d ouvrir Elementor.
- La version distante est relue et confirmée avant de créer la session d intervention.
- La liste Sites affiche `Préparer + Elementor` lorsqu une mise à jour Tech est requise, puis ouvre directement Elementor après préparation.
- Les erreurs de préparation remontent avec un message explicite au lieu du blocage générique `Tech X requis`.
- Tech reste invisible pour le client; seule la boîte de dialogue privée Alliance existe dans Elementor.

# 1.5.7 — Heure de dernier contact corrigée
- Corrige l heure affichée dans **Tech AWM → Sites** : le contact Tech est stocké en UTC mais est maintenant converti dans le fuseau horaire WordPress d Alliance avant affichage.
- Évite le décalage de quatre heures observé lorsque l administration Alliance utilise `America/Toronto` pendant l heure avancée.
- Conserve la valeur brute UTC en stockage afin de garder une télémétrie cohérente entre les sites.
- Ajoute le fuseau horaire Alliance en infobulle sur la colonne **Dernier contact**.
- Applique la même conversion au dernier succès Connector reçu par la télémétrie Tech lorsqu il est stocké au format UTC.

# 1.5.6 — Stabilisation de l intervention Elementor
- Ajoute un préflight côté Alliance : le bouton Elementor n est disponible que si Tech AWM 1.5.6 et Elementor sont confirmés sur le site client.
- Affiche dans l unique boîte Tech l état de connexion et le temps restant de la session privée Alliance.
- Attend automatiquement le chargement de l iframe Elementor avant le mode Sélectionner au lieu d obliger le technicien à réessayer manuellement.
- Réinitialise proprement une sélection devenue obsolète lorsque l aperçu Elementor est rechargé.
- Après Appliquer ou Rollback, recharge l aperçu Elementor sans recharger toute l interface WordPress lorsque l API Elementor le permet.
- Durcit le JavaScript de la boîte Tech pour qu un contrôle absent ne bloque plus toute l intervention.
- Conserve une seule boîte de dialogue Tech et aucune surface sur le front-end public.

# 1.5.5 — Intervention Elementor directe avec une seule boîte de dialogue
- Le bouton d intervention Alliance ouvre désormais directement la page cible dans l éditeur Elementor.
- Supprime la palette Tech du front-end public : aucune surface d intervention n y est rendue.
- Dans Elementor, affiche une seule boîte de dialogue Tech AWM, compacte, déplaçable et réductible.
- La boîte regroupe conversation, sélection d élément, pièces jointes, application, diagnostic et rollback sans ajouter de deuxième palette.
- La session reste temporaire, liée au client, au domaine et à la page, et Tech demeure invisible au client.

# 1.5.4 — Liste des sites visible directement dans Vue d’ensemble
- Affiche la liste d’intervention des sites Hub Client directement sous le tableau de bord Tech AWM, sans devoir cliquer sur un simple lien.
- Conserve l’onglet **Sites** dédié pour la vue complète.
- La liste reste alimentée par CRM canonique + inventaire Core, avec actions **Intervenir**, **Fiche Tech** et **Voir**.
- Corrige le doublon du champ de recherche dans la vue Sites.

# 1.5.3 — Palette Tech dans l’éditeur Elementor
- Corrige la session d’intervention Tech lorsqu’une page est ouverte avec `action=elementor` dans wp-admin.
- La palette privée Alliance est maintenant injectée directement dans l’interface de l’éditeur Elementor et s’ouvre automatiquement pendant une session Tech valide.
- La session reste liée au client, au domaine, à la page et au navigateur via le jeton temporaire; aucune palette n’apparaît sans intervention Alliance active.
- Le mode **Inspecter** cible maintenant le document de prévisualisation Elementor dans son iframe et permet de sélectionner un élément directement depuis l’éditeur.
- Empêche l’affichage d’une deuxième palette dans l’iframe `elementor-preview` afin de garder une seule boîte de dialogue visible.
- Conserve Tech totalement invisible dans le Hub Client et pour les visiteurs.

# 1.5.2 — Section Sites visible et accès direct
- Corrige la navigation Alliance : la section **Sites** est maintenant exposée directement dans le shell Tech AWM.
- Le menu Tech AWM ouvre désormais la liste des sites Hub Client par défaut pour accélérer les interventions.
- La vue d’ensemble reste disponible comme onglet séparé.
- La liste continue d’utiliser uniquement les fiches CRM canoniques et les sites où Hub Client est confirmé installé.
- Tech demeure totalement invisible dans Hub Client et réservé à Alliance Web Marketing.

# 1.5.1 — Liste des sites Hub Client et intervention directe
- Ajoute dans Tech AWM une liste centrale de tous les sites où Hub Client est confirmé installé.
- Réutilise le client_id CRM canonique, le Connector et l’inventaire Core sans créer de répertoire client parallèle.
- Affiche version Hub Client, état/version Tech, mises à jour, alertes, transport Connector et dernier contact.
- Permet de lancer une intervention Tech directement depuis la ligne du site lorsque l’agent est installé et autorisé.
- Conserve un accès à la fiche Tech complète pour activation, permissions, URL cible précise et diagnostic.
- Les sites sans Hub Client confirmé ne sont jamais proposés comme cibles d’intervention.

# 1.5.0 — Centre Tech privé et intervention front-end Alliance

- Tech AWM n est plus un service client : son interface est exclusivement réservée à Alliance Web Marketing.
- Ajoute des sessions d intervention front-end temporaires (20 min), liées au client, au domaine et à la page ciblée.
- La palette Tech est injectée uniquement lorsqu une session Alliance valide est ouverte; elle est invisible aux visiteurs et au Hub Client.
- Ajoute inspection Elementor, diagnostic, design, réparations ciblées, application contrôlée et rollback dans la session privée.
- Ajoute un scan horaire de santé/sécurité : mises à jour disponibles, changements sensibles de baseline, échecs de connexion inhabituels et événements de mise à jour.
- Toutes les interventions sont auditées côté Alliance sans journaliser le jeton de session.

## 1.4.3 — 2026-09-05
- Ajoute un centre de santé Tech AWM dans Hub Client : versions, dernier contact, transport Connector et journal technique récent.
- Ajoute les actions Diagnostic complet, Tester la liaison, Réparer la connexion, Resynchroniser Alliance et Vider les caches AWM.
- Teste séparément REST avec en-têtes, REST avec secret dans le corps HTTPS, admin-ajax et pont frontal, sans journaliser le secret Connector.
- Les actions de réparation exigent un administrateur WordPress et respectent la permission centrale `wordpress_safe_actions`.
- Transmet à Alliance le dernier transport, le dernier succès Connector et le dernier événement Tech via le profil sécurisé existant.

## 1.4.2 — 2026-09-04
- Le runtime Tech utilise le transport Connector résilient de Hub Client pour statut, chat et résultats d'actions.
- Aucun secret supplémentaire ni base client parallèle.

## 1.4.1 — 2026-09-04

- Corrige la vérification d'autorisation Tech entre Hub Client et Alliance sur les hébergements qui filtrent les en-têtes HTTP personnalisés.
- Les appels Tech utilisent le transport Connector HTTPS compatible par corps chiffré en transit, sans exposer le secret dans le navigateur.
- Le statut Tech retourne le `client_id` CRM canonique afin que Hub Client puisse confirmer/réparer son rattachement local.

## 1.4.0 — 2026-09-04
- Corrige le menu principal Thech AWM : il ouvre maintenant son propre tableau de bord au lieu de rediriger automatiquement vers CRM.
- Ajoute une vue d ensemble Tech autonome; seul l onglet Clients ouvre explicitement la recherche CRM canonique.
- Ajoute la fenêtre Tech AWM flottante directement sur le front-end des pages WordPress/Elementor autorisées.
- La fenêtre connaît automatiquement la page courante, son post_id et son contexte Elementor.
- Le mode Inspecter permet de cibler un élément Elementor directement dans la page.
- Corrige les conversations multi-tours OpenAI : les anciens messages assistant sont transmis en output_text et les messages utilisateur en input_text.
- Depuis Hub Client, une URL interne est résolue vers la page WordPress réelle et devient la cible des actions Appliquer / rollback.
- Affiche la page cible dans la conversation pour éviter toute modification ambiguë.

## 1.3.0 — 2026-09-04
- Thech/Tech AWM utilise exclusivement le `client_id` canonique de CRM AWM.
- Le moteur de recherche Clients de Thech ouvre la liste et la fiche client CRM.
- L onglet Tech est injecté dans la fiche client CRM unifiée.
- Activation, permissions, mémoire, diagnostics, consommation et journal restent des données Tech liées au même `client_id`, sans copie de la fiche client.

## 1.2.0 — 2026-09-04
- Remplace la grande table Sites et autorisations par le parcours client canonique du Hub.
- L onglet principal Clients de Thech AWM ouvre désormais le moteur de recherche habituel des fiches clients.
- Ajoute un onglet Tech directement dans chaque fiche client Hub AWM.
- Déplace activation, permissions Chat / Diagnostics / Elementor / WordPress / Fichiers et état du runtime dans cet onglet Tech.
- Conserve l activation exclusivement côté Alliance et journalise les changements de permissions.
- Préserve le contexte Thech AWM dans le shell Premium lorsque la fiche est ouverte depuis Tech.

# Changelog Tech AWM

## 1.1.0 — 2026-09-04
- Devient un paquet physique autonome dans la Suite AWM.
- Regroupe le module central Thech AWM et le runtime client Tech AWM.
- Conserve l'activation exclusivement contrôlée depuis Alliance.
- Réutilise Hub Client et son moteur Elementor sécurisé sans dupliquer les données métier.
- Préserve le shell Premium, la mémoire centralisée, le suivi des tokens, les pièces jointes et le rollback.


---

## README.md

## Tech AWM 1.10.18 — Correctif de l'éditeur Elementor en session administrateur

Le bouton WordPress utilise toujours le compte temporaire à permissions administrateur durant la session AWM. Dans `post.php?action=elementor`, ces permissions sont rétablies avant l'initialisation d'Elementor. La session WordPress n'est pas limitée à une page unique; seules les pages autorisées par WordPress peuvent être modifiées.

Si l'administration WordPress utilise le domaine sans `www` alors que la prévisualisation Elementor utilise `www`, Tech transfère l'éditeur à l'hôte canonique avec un **code à usage unique (≤ 90 secondes)**, puis crée des cookies WordPress uniquement pour cet hôte. Aucun cookie admin généralisé aux sous-domaines. Une autre origine ou un site indépendant ne reçoit aucun accès.

La fenêtre Tech attend que l'aperçu Elementor soit chargé; le frontend et les anciennes sessions Elementor conservent leur fonctionnement. Si Elementor reste bloqué après cette correction, consulter les requêtes `admin-ajax.php`, REST, les logs PHP et le mode sans échec Elementor : un conflit avec une extension, la mémoire PHP ou des données de page peut aussi causer l'écran de chargement. **Aucune modification des pages** ni restauration automatique Unicode.

## Tech AWM 1.10.17 — Journal des interventions et fenêtre WordPress

Les interventions WordPress ouvrent désormais le véritable `/wp-admin/` **sans la fenêtre flottante Tech**. Les privilèges temporaires contrôlés côté Alliance (client CRM actif, site autorisé, session valide) sont conservés, sans divulguer les identifiants du client.

Le module journalise en priorité les événements reconnus par les hooks WordPress dans une **table locale durable**, puis les remonte vers Core AWM lorsque la session de technicien d'origine est encore valide. Le Hub affiche les événements reçus dans `Tech AWM → Journal`. Les recherches sont limitées à une fenêtre récente du journal de sécurité Core; elles ne prouvent pas la complétude de tous les événements de toutes les extensions.

Installation de la Suite 4.5.393 sur Alliance puis mise à niveau de Tech sur le site client à 1.10.17. Valider sur un pilote : ouverture WordPress, action identifiable (ex. modification d'une page de test), entrée dans le journal et état local après déconnexion. Aucun mot de passe/token n'est exporté ni exposé.

## 1.10.16 — Accès WordPress depuis Monitoring

Après import de la Suite 4.5.392, le **site client** doit exécuter Tech AWM 1.10.16. La restauration de session admin se fait avant la construction du menu WordPress; les capacités demeurent dynamiques et révocables. Si le compte temporaire rencontre un autre système de sécurité, consulter les logs `admin_page_denied`, `admin_session_capabilities` ou `admin_bridge_capabilities`. Aucune exception de permission manuelle ni rôle administrateur persistant n'est ajoutée.

## 1.10.15 — Correctif de sécurité de l'éditeur
Hub Client 1.14.20+ est requis pour écrire sur une page Elementor. Les opérations sans widget exact sont refusées. Si une section Elementor est sélectionnée, seules les widgets enfants vérifiés par le serveur sont admissibles; les autres sections sont protégées. La restauration des textes déjà corrompus exige une révision Elementor/WordPress ou une sauvegarde saine, et non une simple mise à jour de plugin.

# Tech AWM 1.10.14 — accès WordPress hérité et réparation du chargement

Tech actif + CRM actif + Hub Client appairé = permission WordPress admin activée PAR DEFAUT (session temporaire uniquement). La case peut être désactivée manuellement : cette exception perdure après désactivation/réactivation Tech. Un ancien champ décoché était hérité de la version où la case était désactivée par défaut; seules les désactivations explicites enregistrées à partir de 1.10.14 servent d'exception durable.

Depuis Monitoring, les formulaires `target=_blank` sont soumis dans l'événement de clic, sans `setTimeout` ni bloqueur central. Un nouvel onglet présente la page WordPress ou un message d'échec Connector/agent. Aucune mise à niveau du plugin client n'est déclenchée au moment de la connexion, pour éviter un chargement interminable : installer Tech >= 1.10.13 sur le site puis synchroniser son profil si l'agent est trop ancien.

Sécurité : autorité centrale, HTTPS, client actif, site/instance exact et audit d'intervention inchangés. Pas de droit administrateur persistant. Essai sur véritable WordPress client requis avant déploiement massif.

# Tech AWM 1.10.13 — Accès WordPress administrateur temporaire et audit

## Fonctions livrées

- **Monitoring > WordPress** : bouton ouvrant une authentification WordPress sans le mot de passe du client, via le Connector authentifié, le `site_id` exact, l'instance jumelée, HTTPS et un code de passage éphémère/à usage unique. Compatible avec les installations en sous-répertoire.
- **Monitoring > Tech sur site** : entrée existante restaurée, avec session technique AWM et les protections précédentes.
- **Administration WordPress complète** : activation/installation/suppression/mise à jour d'extensions, changements de thème, administration des comptes, des contenus et d'Elementor au moyen des capacités d'administrateur WordPress **tant que la session AWM est autorisée**. Le compte temporaire garde au repos un rôle **lecture seule** (sans pouvoir éditer si Tech est désactivé) ; les capacités sont fournies dynamiquement par le moteur de session. Le compte ne permet pas la connexion par mot de passe.
- **Autorisation distincte** : `WordPress : administration complète` est désactivé par défaut, configurable par client dans CRM > fiche Tech > Permissions; l'ancien `Réparations` ne déclenche jamais à lui seul ce niveau d'accès.
- **Audit local et central** : créations, modifications/suppressions de contenu, changements Elementor, médias, extensions et mises à jour, thèmes, utilisateurs/rôles, réglages publics, taxonomies, ainsi qu'une trace de requête de modification (admin/REST/AJAX) pour les extensions tierces non instrumentées. Chaque entrée porte l'ID du technicien, du client, du site, de la session, une date et l'identifiant technique de l'objet. Aucune valeur de mot de passe, cookie ou clé API n'est enregistrée dans le journal.
- **Résilience des audits** : conservation locale et file d'attente jusqu'à 500 événements si le Hub ne répond pas, sans jamais attribuer les événements d'une ancienne session à une nouvelle. État de synchronisation à vérifier en production.

## Garanties et limites

- Seuls les clients CRM actifs et les sites WordPress dont Hub Client est autorisé peuvent ouvrir une session. L'agent Tech **1.10.13 ou ultérieur** doit être installé sur le site cible; l'ancienne session Elementor conserve les privilèges restreints.
- Le compte technique ne devient pas durablement administrateur. Les capacités cessent dès que la session n'est plus valide. Le code de passage est séparé du jeton Connector et le cookie administrateur technique est limité au domaine hôte.
- L'audit des actions à travers les hooks WordPress est détaillé mais ne peut **garantir 100 % des modifications des extensions tierces**. Une requête de modification journalisée n'établit pas à elle seule le succès de l'action. La désactivation du plugin d'audit ou les modifications directes hors WordPress peuvent interrompre la traçabilité; une journalisation serveur indépendante serait nécessaire pour une garantie absolue.
- Les fonctions d'administration réseau multisite (super-admin) ne sont pas incluses. Le site doit utiliser HTTPS. Aucune connexion permanente ou stockage de mot de passe client.
- Tests PHP et contrats locaux réalisés. Le SSO, l'administration d'extensions, la synchronisation des journaux et le comportement des extensions tierces **nécessitent un pilote sur WordPress réel** avant déploiement global.

## Installation

Importer la Suite 4.5.389 puis mettre à jour **Tech AWM 1.10.13 sur le WordPress cible**. Dans la fiche Tech du client, cocher explicitement `WordPress : administration complète`, enregistrer, puis ouvrir Monitoring > WordPress. Confirmer la présence des événements dans Core AWM > Journal de sécurité et Tech local. Désactiver la permission après la validation pilote si elle n'est pas nécessaire.

---
# Tech AWM 1.10.12 — Monitoring unifié

**Tech AWM → Monitoring** affiche une carte par WordPress réellement géré : diagnostics de santé, SSL, zone DNS/NS et destination IP/CNAME, WP-Cron, SQL, contrôles manuels, fiche Tech. Recherche locale par client/domaine/NS/IP, filtres et pagination. Les clients inactifs, les URL de clients sans Hub Client et les Connectors révoqués sont exclus.

**Alertes DNS** : en cas de changement stable, deux mesures espacées d'au moins 30 minutes et une référence antérieure valide sont nécessaires. Le courriel contient la zone, le site et les NS/IP/MX avant/après; il est envoyé uniquement aux adresses de techniciens définies dans **Tech → Réglages → Notifications et escalade**, option « Alertes DNS confirmées ». Les doublons d'une même zone/transition sont supprimés et les changements suspects en attente recontrôlés prioritairement. Les vérifications WP-Cron/SQL restent dépendantes de Tech Client 1.10.11. Aucune modification DNS ni SQL automatique.

**État de validation :** tests locaux, PHP, JS et ZIP; les essais sur une installation WordPress et la synchronisation publique restent à confirmer.

## Suivi de sante Tech 1.10.11

Dans Tech AWM > Monitoring, une grille a quatre indicateurs (SSL, DNS, WP-Cron, SQL) est ajoutee pour les sites des clients CRM actifs avec Connector autorise et Tech active. Les controles SSL/DNS sont repartis par lots de 3 toutes les 15 minutes via WP-Cron sur Alliance, avec controle manuel limite pour chaque site. La sante WP-Cron et SQL utilise une sonde locale en lecture seule avec cache et uniquement des compteurs, jamais du contenu sensible. La fiche Tech reprend une synthese.

**Attention :** un resultat vieux de plus de 36 h cote Alliance ou 48 h pour la telemetrie client est marque a verifier/en attente. Les erreurs TLS temporaires sont confirmees avant journalisation. Les agents Tech anterieurs fonctionnent mais ne publient pas ces nouvelles metriques.

# Tech AWM 1.10.10 — sites WordPress réellement gérés — 2026-10-11

- La page **Protection formulaires** inclut uniquement les sites appartenant à un client **actif dans CRM AWM** ET disposant d’un **Core Site Connector / Hub Client autorisé, non révoqué**. Un domaine conservé pour SEO, Ads, comptabilité ou un autre service ne suffit pas.
- Le lieu d’hébergement n’est jamais un critère : un WordPress externe connecté reste éligible. Un site déconnecté, jamais appairé ou révoqué est absent des listes et compteurs.
- Même filtrage pour propagation globale, synchronisation cron, Appliquer et Vérifier. Le droit du Connector est revérifié juste avant chaque requête distante.
- Aucune suppression : l’historique et les modes particuliers sont conservés jusqu’à une éventuelle reconnexion. Aucune modification de la logique Elementor, des courriels, de CallTracker, de la surveillance HTTP ni des sondes.
- Statut opérationnel CRM et Connectors Core existants réutilisés sans nouvelle table SQL ni logique d’hébergement présumée.
- Validation : tests PHP isolés, contrôle PHP/JS et ZIP; valider sur un site WordPress réel avant propagation massive.

# Tech AWM 1.10.9 — Protection formulaires : clients actifs seulement — 2026-10-11

- **Source de vérité unique : CRM AWM.** La liste des sites est construite avec `CallLink_CRM::operational_clients()`; chaque client est reconfirmé par `operational_client()` avant l'affichage et avant l'envoi distant.
- Les clients **inactifs, archivés ou supprimés** ne sont ni affichés, ni comptés, ni visés par « Enregistrer et propager », les actions Appliquer/Vérifier ou la synchronisation cron.
- Les préférences, compteurs et erreurs historiques des clients masqués restent en base. Ils réapparaissent avec leurs réglages lors d'une réactivation officielle dans le CRM.
- Les synchronisations en attente des clients inactifs ne provoquent plus de relance planifiée infinie; seules les cibles actives sont reprises.
- Si le CRM n'est pas disponible, la liste est vide plutôt que de réintégrer des clients dont le statut est inconnu (échec sûr).
- La page précise « sites actifs ». Aucun changement au CSS, au filtrage Elementor, aux emails, webhooks, CPL, sondes HTTP, Recovery ou à l'agent Hub Client.
- Tests locaux isolés : 17 cas PASS; validation en production WordPress à confirmer.

# Tech AWM 1.10.8 — Protection formulaires : harmonisation UX / CSS — 2026-10-11

- Harmonisation de **Tech AWM → Protection formulaires** avec les surfaces, bordures, typographies et variables clair/sombre du shell AWM, sans styles codés en blanc.
- En-tête Tech / Sécurité, indicateurs lisibles, sections « Protection par défaut » et « Protection par site » avec instructions courtes.
- Liste compacte de 84+ sites au lieu de grandes cartes en deux colonnes, états explicites, version Hub Client, compteurs issus du dernier relevé, diagnostics d'erreur.
- Recherche client/domaine avec accents, filtres des états, pagination locale 15/30/60 et état vide informatif, sans appel AJAX supplémentaire.
- Boutons **Appliquer** et **Vérifier** restent distincts et liés au bon client_id/site_id et à leurs nonces; choix global et exception par site préservés.
- Retour à la ligne de travail après une action par site dans le même onglet grâce au stockage temporaire du filtre/page, sans ajouter le nom du client à l'URL.
- Responsive tablette/mobile sans défilement horizontal et sans texte illisible; meilleure accessibilité (labels, focus clavier, contrastes, préférence réduction des animations).
- Un garde-fou de compatibilité conserve **Tech 1.10.7** comme version minimale du runtime client : une mise à jour d’interface sur le Hub ne force pas la mise à niveau de 84 agents clients.
- **Aucun changement** aux règles anti-spam, à la validation Elementor, au routage des courriels/LeadTracker, à Hub Client, aux sondes HTTP, aux permissions, à Recovery ou au CPL.
- Tests locaux de rendu PHP sur 84 sites simulés et vérifications navigateur Chromium en modes sombre/clair, bureau/tablette/mobile. Validation en production WordPress et Elementor Pro à confirmer.

# Tech AWM 1.10.7 — Surveillance HTTP fiable et diagnostics actionnables

Le Centre d'opérations distingue désormais **une erreur observée par une sonde** d'une
**panne confirmée à plusieurs passages espacés**. Un seul échec peut être causé par DNS,
TLS, timeout ou WAF. Les mails ne disent plus « site totalement hors ligne » sans preuve.

- Une seule sonde par passage de WP-Cron : les retries dans la même seconde ne sont
  plus comptés comme deux contrôles indépendants.
- Deux sondes HTTP 4xx/5xx espacées d'au moins 90 s : incident ERROR documenté.
- Trois contrôles avec absence de code HTTP, sur au moins 210 s : CRITICAL justifié
  **du point de vue de la sonde centrale**. Ce n'est pas une mesure multi-régions.
- La file remet les anomalies en tête au prochain passage, sans monopoliser le parc.
- Délai de 7 s, requête GET sans `Range` ni `no-cache`; HTTP 401/403/429 reste WARNING.
- Courriels et escalades : URL réellement testée, codes WP_Error/HTTP, message,
  horodatages UTC, nombre et durée des sondes, lien direct vers les alertes.
- Fiche site Tech : cause brute du dernier contrôle et horodatage, libellé
  « Échec sonde (à confirmer) » au lieu de « Hors ligne » avant corroboration.
- Anti-bruit : courriels de même incident HTTP limités à une émission par 30 minutes.

Le correctif ne change **aucun autre module**, ni formulaire Elementor, ni
CallTracker/CPL, ni Recovery, ni la structure SQL. Le flux réel doit être validé
sur un site pilote avant généralisation à la flotte.

# Tech AWM 1.10.6 — Centre anti-spam Elementor multi-sites
**Tech AWM → Protection formulaires** regroupe les protections des formulaires Elementor sur les WordPress clients du CRM.

- Une règle générale (Standard par défaut, Surveillance, Strict, Désactivé) et un choix « Hériter »/override par site.
- Un bouton **Enregistrer et appliquer aux sites** pour propager les réglages en lots WP-Cron de 4 sites, sans bloquer le navigateur pendant 80 installations.
- Canal Core AWM `client_agent_request` existant, authentifié par secret de scan propre au site : vérification du client, du site, de l'instance WordPress et de l'ACK du mode appliqué.
- Statuts honnêtes « En attente / Appliqué et confirmé / Connexion à vérifier », bouton Vérifier et compteurs de blocage relevés localement. Un site ancien ou hors ligne n'est **jamais** affiché comme protégé avec confirmation.
- Découverte quotidienne des nouveaux sites et nouvel essai des sites en échec. Aucune donnée personnelle des leads dans Tech.

**Ordre** : installer Suite sur Alliance et Hub Client 1.14.19 sur chaque site, puis Tech AWM → Protection formulaires → Standard → Enregistrer et appliquer. Valider un formulaire de production sur un premier site avant lancement sur la flotte.

# Tech AWM 1.10.5 — composant systeme actif par defaut

Tech AWM est autorise par defaut pour tout client valide. Une indisponibilite temporaire de la resolution CRM ne peut plus le faire apparaitre desactive. Seule une desactivation explicite en fiche client est persistante. Core 4.5.262 peut ainsi installer, activer et mettre Tech a niveau avant Recovery sur chaque site connecte.

# Tech AWM 1.10.3 — canal de secours Hub Client autonome
Tech expose maintenant une route de secours minimale, chargée même lorsque Hub Client est inactif. Elle est authentifiée par le secret de scan déjà appairé au site et ne peut réactiver que `hub-client-awm/hub-client-awm.php`. Elle ne permet ni installation arbitraire, ni exécution de commande, ni contournement Recovery.

# Tech AWM 1.10.2
- L automatisation des extensions démarre immédiatement après activation d une politique Automatique.
- Le worker conserve son état et distingue les blocages Recovery des vraies erreurs.
- Les inventaires sont rafraîchis avant action et le statut Recovery est conservé par site.
- Les interventions Frontend/Elementor de 1.10.1 restent inchangées.

# Tech AWM 1.10.1

Correctif d intervention : passage WordPress temporaire et sécurisé pour ouvrir Elementor/frontend sans demander les identifiants du site client. La session reste liée au client, au site, à l installation WordPress, au domaine, à la page et aux scopes Alliance.

# Tech AWM 1.10.0 — mises à jour guidées

La page **Mises à jour** est maintenant organisée pour qu'un stagiaire puisse travailler sans comprendre l'architecture interne de la Suite.

Le parcours normal est :
1. **À faire maintenant** : choisir un site qui demande une action;
2. **Mettre à jour ce site** : Tech exécute uniquement les extensions actives et admissibles, puis revérifie l'inventaire;
3. ouvrir le détail seulement si une extension inactive, un module AWM, WordPress ou un thème demande une vérification particulière.

L'installation est séparée dans son propre onglet. On choisit une seule fois le **site de destination**, puis on installe un module AWM signé Core ou une extension WordPress approuvée.

Les fonctions techniques (versions de la Suite, politique automatique globale, inventaire complet, action sur tout le parc, WordPress et thèmes) restent disponibles dans **Avancé**, mais ne sont plus mélangées au travail quotidien.

## Tech AWM 1.9.4 — mise à jour protégée des extensions
La vue Mises à jour utilise désormais directement le canal Hub Client signé pour les extensions tierces. Une mise à jour manuelle privilégie Recovery complet puis peut utiliser le secours local borné de Hub Client 1.13.2. Elementor Pro est supporté si le site lui-même expose une mise à jour HTTPS valide via sa licence. L automatique reste plus strict que le manuel.

## Tech AWM 1.9.3
La session d intervention est maintenant glissante tant que le technicien reste actif. Les transformations rédactionnelles d un élément sélectionné ne dépendent plus du modèle général pour choisir le champ Elementor : Tech choisit le path compatible et demande uniquement la nouvelle valeur, puis conserve le flux proposition → application → snapshot → rollback.

# Tech AWM 1.9.2 - REST canonique www/apex
La fenetre Tech utilise maintenant l origine effectivement ouverte dans le navigateur lorsque `rest_url()` differe seulement par l alias `www`/apex. Le cookie WordPress, le nonce `wp_rest` et la session Alliance restent ainsi disponibles pendant le passage frontend <-> Elementor. Les permissions `edit_post` restent obligatoires.

# Tech AWM 1.9.1 — session REST WordPress stable
La fenêtre Tech transmet maintenant le nonce REST WordPress avec chaque appel. Une session peut donc passer du frontend à Elementor puis revenir au frontend sans perdre l utilisateur WordPress authentifié ni déclencher un faux `awm_tech_target_forbidden`. Les permissions `edit_post` restent vérifiées côté serveur.

# Tech AWM 1.9.0

## Moteur Elementor généralisé
Tech peut maintenant transformer une demande naturelle en action réversible sur les widgets, containers, sections et colonnes sélectionnés. Les éléments tiers restent limités aux réglages universels sûrs.

# Tech AWM 1.8.6
Tech AWM peut maintenant convertir de facon deterministe une demande redactionnelle sur un widget Elementor selectionne en action reversible meme si le premier passage IA ne fournit pas d action. Le fallback ne touche qu au champ texte compatible du widget selectionne et repasse par les gardes de permissions, SHA-256 et rollback.

## Tech AWM 1.8.5 — garde distante restaurée
La conversation Frontend restaure la garde interne `remote_status()` et la lecture centralisée des permissions qui avaient été retirées accidentellement lors du refactor de navigation 1.8.2. Une indisponibilité du canal distant retourne maintenant un `WP_Error` explicite au lieu d un fatal PHP. Le contexte widget ciblé et le diagnostic détaillé de 1.8.4 sont conservés.

## Tech AWM 1.8.4 — conversation ciblée robuste
Les demandes sur un élément Elementor sélectionné utilisent maintenant un contexte local minimal construit directement depuis `_elementor_data`. Le widget réel, ses champs modifiables et le hash du document sont transmis sans reconstruire toute la page. Les exceptions du pipeline de conversation sont identifiées par étape et visibles dans le diagnostic privé Tech.

## Tech AWM 1.8.3 — Frontend stable et conversation cible compacte
La fermeture X devient un vrai masquage du panneau avec lanceur unique. Pour une demande sur un bloc selectionne, la conversation envoie seulement le widget Elementor cible et son contenu editable, ce qui accelere les reecritures et evite les payloads de page inutiles. Les erreurs de conversation sont maintenant codees et journalisees.

# Tech AWM 1.8.2 — session d intervention persistante sur le frontend
Une intervention ouverte depuis **Elementor avancé** peut maintenant suivre le technicien sur les pages du même site WordPress tant que la session Alliance est valide et que l utilisateur WordPress reste connecté avec le droit de modifier la page courante. La fenêtre Tech réapparaît automatiquement après chaque navigation, la page courante devient la cible active et le fil de conversation conserve son `thread_id` dans la session navigateur.

Le panneau possède maintenant un bouton **Fermer Tech AWM**. Fermer masque la fenêtre sans terminer la session et laisse un petit lanceur **Tech AWM** pour la rouvrir. L état fermé/ouvert reste cohérent pendant la navigation de la session.

Sécurité : le jeton reste HttpOnly, n est jamais conservé dans l URL, chaque nouvelle page est revalidée côté Alliance avec `client_id + site_id + instance_uuid`, domaine/répertoire canonique et utilisateur WordPress autorisé. Aucun visiteur public/non connecté ne voit la fenêtre.

# Tech AWM 1.8.1 — intervention exacte, alias www sûr
Tech accepte maintenant `www.example.com` et `example.com` comme alias du même site lorsque Core les a déjà liés au même `site_id`. La validation d intervention reste fail-closed sur le port, HTTPS et le répertoire WordPress. Les sous-domaines distincts, chemins parents et chemins ambigus restent refusés.

# Tech AWM 1.8.0 — Modules AWM
Tech devient l interface d orchestration des modules privés de la flotte. Le panneau **Modules AWM** affiche uniquement ce que la publication Core active autorise à poser à distance. La sécurité et les paquets restent dans Core; le site client exécute le déploiement via Hub Client et `atomic_v2`.

Tech affiche aussi le statut MU de Hub Client afin qu un technicien puisse distinguer un agent traditionnel d un agent système protégé.

# Tech AWM 1.7.40 - Suite 4.5.250

Tech utilise maintenant un bootstrap d activation minimal sous le sandbox WordPress. Le runtime complet n est jamais chargé pendant `activate_plugin()`; il démarre seulement sur la requête suivante, ce qui élimine les collisions avec une ancienne version encore en mémoire pendant un remplacement distant.

# Tech AWM 1.7.39 - Suite 4.5.248

## 1.7.39 — bootstrap client résilient après mise à jour distante — 2026-09-22
- Corrige le pilote Allo Déménagement : Hub Client 1.11.50 s installe, mais la première requête après remplacement de Tech pouvait répondre par la page WordPress « erreur critique ».
- Le runtime client Tech n est plus chargé pendant `plugins_loaded`; il est démarré plus tard avec garde `Throwable` et classes anti-doublon.
- Les requêtes privées Hub Client `update/status`, `update/apply` et `update/rollback` restent volontairement légères : elles exposent la version Tech sans charger le runtime Elementor complet.
- Une erreur de bootstrap Tech est mémorisée localement sans chemin serveur absolu afin de protéger le site et faciliter le diagnostic suivant.
- Les fonctions Tech/Elementor restent chargées sur les requêtes normales, REST Tech, admin et frontend; aucune permission ni signature n est assouplie.
- L autopilote Recovery reste suspendu.

# Tech AWM 1.7.38 - Suite 4.5.243

## 1.7.38 — Accès au site manuel compatible Recovery suspendu — 2026-09-22
- Le clic administrateur **Accès au site** est maintenant traité comme une intervention manuelle explicite.
- Si Hub Client ou Tech doit être préparé avant l ouverture de la session, Tech appelle Core avec `manual=true` et le `site_id` exact.
- Le chemin manuel conserve canal signé, SHA-256, sauvegarde/rollback fichiers et vérification de version.
- L autopilote reste suspendu et aucun déploiement implicite ne contourne Recovery.
- Correction pertinente après migration d hébergement : une preuve RESTORE_TEST peut être invalide sur la nouvelle topologie, sans empêcher une intervention manuelle protégée.

# Tech AWM 1.7.37 - Suite 4.5.235

## 1.7.37 — Etat Recovery exploitable par le Tech — 2026-09-15
- Les cartes Recovery du parc distinguent route de secours, périmètre de sauvegarde et vrai test de restauration.
- `Recovery prêt` ne signifie plus que l'URL répond : l'interface montre explicitement si l'automatisation reste interdite.
- Aucun changement de privilège : un Tech AWM reste administrateur par défaut, avec restrictions explicites possibles.

Date : 2026-09-15

Boutons Recovery relies aux identites nominatives via Core, acces aux portes clientes deja verifiees meme si WordPress est maintenant indisponible. Moteur de mise a jour protege sur version cible exacte et suivi de resultats. Bibliotheque centrale accessible depuis Core.

Candidate de stabilisation. Aucun deploiement effectue. Recette reelle WordPress + MySQL/MariaDB + PHP-FPM/OPcache + HTTPS et watchdog systeme obligatoire avant activation. Autopilote Suite AWM toujours suspendu. Les paquets des nouvelles mises a jour tierces proviennent encore du fournisseur WordPress de chaque site; leur telechargement unique depuis Alliance reste au roadmap.

Voir le guide Recovery embarque et les notes de livraison.

## Documentation anterieure conservee

## 1.7.35 — bouton Recovery et portes de secours du parc — 2026-09-14

- Ajoute **Recovery** dans le shell Tech, a cote des controles du dashboard, et un sous-menu Recovery.
- La page Recovery liste le Hub central et chaque Hub Client ayant annonce une porte de secours HTTPS.
- Les fiches/sites Tech affichent directement le bouton Recovery lorsqu il est disponible.
- La porte ouvre la meme interface Recovery locale hors WordPress; Tech ne duplique pas le moteur de restauration.
- Le niveau 1 reste limite au dernier point stable recommande par le moteur; les restaurations BD ne sont pas exposees dans Tech.

## 1.7.34 — Morning Brief Health transversal — 2026-09-12

- Le Brief AWM affiche le score Health Suite /100 et ses raisons de vigilance tout en conservant incidents, SLA et priorités comme autorités opérationnelles.
- Le score Health est rafraîchi avec le snapshot du cockpit et reste strictement informatif.

## 1.7.33 — Pulse opérationnel transversal — 2026-09-12

- Expose au Core un pulse incidents ouverts / critiques afin d alimenter la santé système transversale.
- Le pulse est en lecture seule et ne remplace pas les préflights, actions recommandées ou preuves Tech.

# Tech AWM 1.7.32 — préflight intervention, tournée Tech et capacité

- **Livré** : la fiche Tech affiche un préflight avant intervention à partir des preuves runtime disponibles : Connector, permissions d écriture WordPress et comportement OPcache.
- **Livré** : un état inconnu reste explicitement **À vérifier**; Tech ne déduit jamais qu un site est prêt lorsqu une preuve manque.
- **Livré** : la fenêtre Incidents regroupe les incidents par **client + site** dans une tournée Tech suggérée, triée par score maximal puis incidents nouveaux, afin de réduire les changements de contexte.
- **Livré** : une vue **Capacité Tech** montre ouverts, nouveaux, sites concernés, plus ancien incident, SLA dépassés/à risque et score maximal par responsable, avec un bloc Non assigné distinct.
- **Sécurité** : aucune réaffectation ni action sensible n est automatique; le préflight n expose aucun chemin serveur, secret Connector ou clé API.
- **Gouvernance** : ROADMAP, CHANGELOG, notes et validation/logs sont synchronisés avec Suite AWM 4.5.229.

# Tech AWM 1.7.31 — priorité opérationnelle et historique 24 h / 7 j

- **Livré** : score impact × urgence × confiance visible sur chaque incident, avec les trois composantes affichées.
- **Livré** : file d actions recommandées contextuelles dans la gestion des incidents.
- **Livré** : fiche Tech avec historique 24 h / 7 j basé sur les événements existants.
- **Sécurité** : aucune action sensible n est exécutée automatiquement; les permissions et confirmations existantes restent obligatoires.
- **Gouvernance** : ROADMAP, CHANGELOG, notes et validation/logs sont synchronisés avec Suite AWM 4.5.228.

## Tech AWM 1.7.29 — diagnostic Wordfence V3 clair et non bloquant

- Le refus Wordfence Intelligence n ouvre plus une fenêtre globale bloquante : l état apparaît directement dans le panneau Sécurité et le reste de la page demeure utilisable.
- Un HTTP 401 est identifié explicitement comme **clé Wordfence Intelligence V3 refusée** et explique que la clé doit provenir de **Wordfence > Account > Integrations**, pas de la licence du plugin Wordfence installée sur un site.
- Le panneau propose **Retester maintenant**, **Configurer la clé** et **Wordfence Integrations** sans exposer le secret et sans distribuer la clé aux sites clients.
- Le KPI Journal gratuit distingue désormais **Actif**, **Clé refusée**, **À vérifier** et **À configurer** au lieu d afficher Actif dès qu un secret existe.
- Les erreurs 429, réseau ou réponse invalide restent non bloquantes et conservent le dernier diagnostic utile; aucun faux résultat de vulnérabilité n est inventé.
- Le bloc de diagnostic suit la typographie personnelle Tech et reste responsive.
- ROADMAP, CHANGELOG, notes de livraison et rapport de validation sont synchronisés avec la version.

## Tech AWM 1.7.28 — alertes actionnables, overlays lisibles et Moniteur personnalisable

- Toutes les annotations de **Priorités du parc** liées à un site sont maintenant entièrement cliquables, pas seulement les situations corrélées : cliquer n importe où sur une ligne ouvre la fiche Tech complète du site.
- La fiche ouverte depuis une alerte fournit le résumé technique existant et ses actions contextuelles : ouverture du site, détails techniques, contrôles, Connector, mises à jour ou autres actions déjà autorisées selon l état réel du site.
- Les lignes cliquables affichent un indice visuel et une indication **Cliquer pour le résumé complet et les actions**; les actions sensibles conservent leurs confirmations et permissions existantes.
- La **Typographie dashboard** personnelle s applique désormais aussi aux fenêtres Tech, notamment **Priorités du parc**, filtres, annotations, résumés, historiques, boutons d intervention et fiches site ouvertes en overlay.
- Le **Mode moniteur** utilise maintenant le même moteur de personnalisation de blocs que le dashboard : visibilité, ordre, drag & drop, grille 12 colonnes et largeurs 1/4, 1/3, 1/2, 2/3, 3/4 ou pleine largeur.
- La disposition du Moniteur est indépendante de celle du dashboard et reste enregistrée par `user_id`; un Tech peut donc construire un écran mural différent de son poste de travail.
- La **Typographie Moniteur** conserve la priorité en Mode moniteur, y compris lorsque les blocs sont redimensionnés ou déplacés.
- ROADMAP, CHANGELOG, notes et rapports de validation sont synchronisés avec cette livraison.

## Tech AWM 1.7.27 — édition de grille sans panneau superposé

- Quand le Tech choisit le préréglage **Personnalisée**, le panneau de personnalisation se ferme automatiquement afin de rendre tout le dashboard disponible pour le drag & drop.
- Un bouton **Déplacer les blocs** permet aussi d entrer directement dans ce mode lorsque la disposition enregistrée est déjà personnalisée.
- Pendant le déplacement, une barre compacte reste en bas de l écran avec **Annuler** et **Enregistrer mon tableau**; le panneau flottant ne masque plus la carte ni les autres blocs.
- Ouvrir de nouveau l icône Personnaliser met le déplacement en pause sans perdre la disposition de travail; fermer le panneau sans sauvegarder restaure les préférences enregistrées.
- Les raccourcis, blocs visibles, typographie, profils 1080p/4K, grille 12 colonnes et responsive interne restent sauvegardés par `user_id`.

## Tech AWM 1.7.26 — dropdown de liens, blocs container-responsive et typo des fiches

- `Liens personnalisés` devient un dropdown compact directement dans la zone d actions de l en-tete Tech, avant Personnaliser et Light/Dark; les raccourcis ne consomment plus de largeur en permanence.
- `Fermer` du panneau Personnaliser devient un vrai bouton compact avec icone, cohérent avec le reste du shell.
- La Carte utilise maintenant la largeur réelle de son bloc : les périodes se réorganisent en 4 puis 2 colonnes au lieu de déborder sur le bloc voisin.
- `État des sites` abandonne le défilement horizontal lorsque la colonne devient insuffisante : chaque ligne se transforme automatiquement en carte avec libellés, puis en pile verticale sur les petites zones.
- Les blocs étroits utilisent des container queries : la décision de passer en mode compact dépend de la largeur du bloc 1/4, 1/3, 1/2, etc., pas seulement de la largeur globale du navigateur.
- La **Typographie dashboard** personnelle suit maintenant aussi la fiche Tech, ses onglets, métriques, SEO, WordPress, sécurité, historique, boutons et cartes de sites; l échelle reste propre à chaque `user_id`.
- Les préférences par `user_id`, la grille 12 colonnes, les ratios, le drag & drop, les profils 1080p/4K et les données de monitoring restent inchangés.

## Tech AWM 1.7.25 — en-tete compact et dropdown Dark

- Les raccourcis personnels quittent la grande barre sous le shell et sont maintenant injectes directement dans l en-tete Tech, a cote du contexte du module.
- Le bouton Personnaliser devient une icone compacte placee immediatement a gauche du bouton Light/Dark; la rangee supplementaire du dashboard est supprimee.
- Les raccourcis restent propres a chaque `user_id`, defilent horizontalement si l espace devient trop etroit et ne forcent plus une carte pleine largeur en hauteur.
- Le dropdown Prereglage et tous les selects du panneau Personnaliser utilisent maintenant un schema de couleur natif coherent en Dark et Light; les options ne peuvent plus apparaitre blanc sur blanc.
- Aucun changement au moteur grille 12 colonnes, aux ratios, au drag & drop, aux donnees de monitoring ni aux Connectors.

## Tech AWM 1.7.24 — grille responsive personnalisable

- Le dashboard utilise maintenant une grille 12 colonnes avec ancrage automatique et largeurs 1/4, 1/3, 1/2, 2/3, 3/4 ou pleine largeur.
- Chaque Tech peut déplacer les blocs directement en mode Personnaliser; le drag & drop réordonne la grille sans positionnement libre au pixel près.
- Chaque bloc conserve sa largeur et son ordre par `user_id`; un Tech peut donc afficher Visites verticalement en 1/3 tandis qu un autre l affiche horizontalement en 3/4.
- Les blocs changent leur présentation interne selon leur largeur : Top sites peut s étaler sur deux colonnes, KPI se recompone, Timeline et Carte deviennent compactes lorsque leur zone est étroite.
- Pour les paires Carte/Visites et Timeline/Incidents, une largeur 3/4 ajuste automatiquement le compagnon à 1/4 (et 2/3 à 1/3) lorsque les deux blocs sont voisins, afin de remplir proprement la rangée.
- Le responsive protège la mise en page : ratios personnels conservés sur bureau/1080p/4K puis empilement automatique lorsque l écran devient trop étroit.
- La taille de typographie personnelle est appliquée aussi aux textes secondaires du dashboard afin d éviter les éléments qui restent minuscules.
- Un bouton Réinitialiser la grille restaure la disposition AWM standard 2/3 + 1/3.

## Tech AWM 1.7.23 — flotte, bibliothèque et dashboard personnel

- Gestion globale Automatique/Manuel des extensions tierces actives et bouton Tout mettre à jour avec confirmation succès/échecs.
- Boutons de mise à jour harmonisés au CSS des autres actions Tech.
- Bibliothèque AWM initiale d extensions WordPress.org approuvées, installables à distance sur un site Hub Client connecté.
- Dashboard personnalisable par utilisateur Tech : blocs visibles, raccourcis personnels, disposition Standard/Carte en premier/Sites en premier, taille de typo réglable finement, profil Moniteur Auto/1080p/4K et taille Moniteur.
- Préférences enregistrées par utilisateur via AJAX, sans rechargement de page.
- La roadmap publique reste obligatoire et synchronisée avec la publication Suite active.

# Tech AWM 1.7.22

Cette version fiabilise le Mode moniteur lorsqu il est casté avec Chromecast et réduit les rechargements complets de page pour les actions techniques courantes.

Points clés : bouton Économiseur immédiat, minuterie robuste, réveil uniquement sur nouvelle critique, vérification de site sans rechargement, mises à jour individuelles ou groupées sans perdre la position de travail.

Cette version uniformise toute la page Réglages avec le langage visuel validé pour le Mode moniteur : cartes plus lisibles, champs plus grands, contraste Dark renforcé et barres d action cohérentes.

# Tech AWM 1.7.20

Les statuts de la fiche multi-sites sont maintenant actionnables : À connecter ouvre le Connector exact, À vérifier relance le contrôle du site lorsqu il est connecté, et les actions principales partagent une hauteur uniforme.


La fiche client Tech devient réellement multi-sites : le principal et chaque secondaire ont une fiche distincte avec URL complète. Le technicien peut forcer une vérification immédiate des états/mises à jour puis lancer une mise à jour tierce trouvée (par exemple SEOPress) sans attendre le cycle automatique. Les réglages Mode moniteur sont enregistrés par une route dédiée et leur CSS est renforcé.

# Tech AWM 1.7.18

Tech transforme le **Mode moniteur** en affichage dédié au centre d opérations : shell WordPress/AWM masqué, typographie agrandie, thème accessible directement dans la barre carte et économiseur d écran natif au navigateur. L économiseur peut démarrer après 1, 5, 10 ou 30 minutes, utiliser un mode Minimal, Opérationnel ou Rotation, réduire la luminosité, s activer rapidement la nuit et réveiller automatiquement le dashboard si l état devient Critique.

La fiche Tech devient une **console opérationnelle** pensée pour la décision rapide : en-tête compact et actionnable, barre Santé du site, zone À faire, puis onglets Vue d’ensemble / SEO / WordPress / Sécurité / Historique. Les valeurs normales deviennent discrètes et les anomalies restent prioritaires visuellement.

La vue d’ensemble résume disponibilité, HTTP, indexation, vulnérabilités, mises à jour, versions Hub/Tech et dernier contact. Le détail SEO et l’inventaire WordPress complet restent accessibles dans leurs onglets; WordPress ajoute des filtres Tous / À mettre à jour / Auto / Manuel / Inactifs.


La fiche Tech devient le résumé opérationnel complet du site : diagnostic SEO/indexation détaillé, inventaire des extensions WordPress et accès aux mises à jour. Le Centre d opérations utilise maintenant un **Mode moniteur** ouvert dans une fenêtre dédiée pour plein écran/cast. Les rangs Top sites reprennent la même teinte que les points de carte.

Tech AWM 1.7.14 — maintenance WordPress pilotable, diagnostic d indexation et carte multi-sites lisible.

`Mises à jour` affiche maintenant **toutes les extensions WordPress** remontées par chaque installation Hub Client. Le technicien choisit `Manuel` ou `Automatique` pour une extension précise sur un site précis, ou lance `Mettre à jour maintenant`. Les modules AWM restent séparés et continuent seulement par le canal Suite signé Core.

Chaque site expose aussi un diagnostic **Indexable / No-index / À vérifier** avec sa cause. Le contrôle croise le réglage WordPress, les en-têtes HTTP robots, la meta robots de l accueil et `robots.txt`.

Sur la carte du Centre d opérations, un client garde une même famille de couleur et chacun de ses sites reçoit une teinte distincte. La légende et les popups montrent **Principal / Secondaire** ainsi que l **URL complète exacte** configurée, y compris sous-domaines et sous-dossiers.

Tech AWM 1.7.13 — densité du Brief AWM : résumé SLA sur une ligne et cartes de priorités plus minces.

Le bloc **Action immédiate requise** n utilise plus une grande colonne verticale pour ses métriques. À largeur bureau, le titre, les mesures SLA, les fenêtres 7/30/90 jours et le bouton Priorités partagent maintenant une seule barre compacte. Les trois situations prioritaires restent juste dessous dans des cartes plus minces. Aucune information opérationnelle ni logique de polling n est retirée.

Tech AWM 1.7.12 — correctif de stabilité du Centre d’opérations (carte Leaflet + graphique après initialisation SLA).

# Tech AWM 1.7.11 — objectifs SLA configurables

Tech AWM transforme maintenant les mesures MTTD, prise en charge et MTTR en SLA réellement configurables sans inventer de cible. Les réglages globaux acceptent une valeur de `0` pour signifier **objectif non défini**; dans ce cas Tech continue de mesurer les délais mais n affiche aucune conformité contractuelle fictive.

Les objectifs peuvent être surchargés par client puis par site depuis la fiche CRM → Tech. L héritage est strict : **site → client → global**. Le Centre d opérations offre des fenêtres SLA **7 / 30 / 90 jours**, affiche la conformité uniquement sur les échantillons associés à une cible explicite et indique par site `Respecté / À risque / Dépassé / Échantillons insuffisants / Objectif non défini`. Le statut `À risque` correspond à une moyenne située entre 80 % et 100 % de la cible configurée.

Cette version ne modifie pas la DB Tech 1.2.0 et ne change ni les Connectors, ni les incidents, ni les données historiques. Elle prépare le raccord futur aux objectifs de service/contrat CRM via le filtre `awm_thech_sla_targets`, sans créer de second système de facturation ou de contrat.

Les notifications ajoutent aussi une **escalade optionnelle sans prise en charge**. Elle est désactivée par défaut : après activation, un incident `error/critical` encore `Nouveau`, non reconnu et ouvert depuis le délai configuré reçoit une seule escalade courriel. La prise en charge, la résolution ou l inactivation CRM empêchent l escalade. L événement `email_escalated` est ajouté à l historique append-only uniquement après un envoi réussi.

## Tech AWM 1.7.9 — filtres de prise en charge et SLA compact

Le Centre d opérations permet maintenant de filtrer immédiatement les incidents par état humain, responsabilité et criticité. Un technicien peut isoler ses incidents, les nouveaux incidents non assignés ou uniquement les cas critiques sans quitter le popup. La vue Priorités ajoute aussi des filtres par criticité et par type de signal afin de réduire le bruit sans masquer les données brutes.

Le Brief AWM affiche un **SLA Alliance sur 30 jours** sous forme compacte : incidents observés, délai moyen de prise en charge, MTTR et taux de prise en charge. Tech ne présente pas un faux MTTD : le vrai délai de détection restera non disponible jusqu à ce qu un timestamp de premier signal/anomalie soit instrumenté distinctement de l ouverture confirmée de l incident.

## Tech AWM 1.7.8 — gestion opérationnelle des incidents

Tech AWM transforme maintenant le registre d incidents en file de travail Alliance. Chaque incident confirmé conserve son état technique, mais ajoute un workflow humain `Nouveau / Pris en charge / Résolu`, un responsable, des notes et un historique horodaté. Le Centre d opérations permet de prendre en charge, documenter et résoudre un incident sans quitter le popup.

La résolution manuelle ne peut pas cacher durablement une panne : si les sondes ou le Connector confirment encore le même signal au prochain cycle, un nouvel incident est créé. Les résolutions automatiques et manuelles restent distinguées dans l historique.

## Tech AWM 1.7.7 — contexte directement dans l en-tête

Le Centre technique Alliance, la version Tech et l indication de session réservée sont maintenant intégrés au shell principal. Le second bloc de contexte est supprimé afin de concentrer davantage le cockpit.

## Tech AWM 1.7.6 — cockpit compact

Le Centre d’opérations concentre davantage l’information au-dessus de la carte sans retirer les détails disponibles dans les popups. L’en-tête, l’état opérationnel, la surveillance, les six priorités cliquables et le Brief AWM utilisent désormais une densité compacte afin que la carte, l’activité temps réel et les incidents soient visibles plus haut sur un écran standard.

Les six cartes actionnables restent présentes et cliquables; seul le texte répétitif « Cliquer pour voir le détail » est retiré visuellement. Le Brief AWM conserve ses trois situations corrélées mais sous forme de bande compacte. Les vues tablette/mobile repassent automatiquement à 3, 2 puis 1 colonne selon l’espace disponible.

## Tech AWM 1.7.5 — Timeline universelle v1

Le Centre d’opérations aligne maintenant les événements réels des dernières 24 heures dans une **timeline universelle du parc** : incidents ouverts/résolus, sondes HTTP anormales, actions Tech, formulaires Stats AWM et mises à jour détectées. Chaque événement conserve `client_id + site_id` lorsqu’ils sont connus et ouvre la fiche Tech du site sans mélanger les données d’un autre client.

La timeline possède des filtres rapides Tout / Incidents / Tech / Stats / Sondes / Mises à jour et se rafraîchit avec le polling silencieux existant. Les popups de site incluent aussi leur chronologie récente. Cette v1 ne prétend pas encore corréler une cause entre les événements; elle fournit la matière temporelle nécessaire aux futures analyses avant/après et au moteur de cause probable Health.

## Tech AWM 1.7.4 — Brief AWM et corrélation des priorités

Le Centre d’opérations regroupe maintenant les signaux actifs par site afin qu’un même problème potentiel n’apparaisse plus plusieurs fois dans la carte Priorités. Le regroupement reste déterministe et transparent : il indique le nombre de signaux reliés au même site, mais ne prétend pas connaître automatiquement la cause.

Un nouveau **Brief AWM** résume l’état du parc sous les cartes principales et remonte les trois situations les plus importantes avec accès direct à la fiche Tech du site. Le brief se met à jour avec le polling silencieux sans recharger la page.

## Tech AWM 1.7.3 — cockpit priorités + trafic live

La vue globale place maintenant les signaux qui demandent une action en premier : priorités, incidents, 404 sondées, mises à jour importantes, formulaires et sites à surveiller. Toutes ces cartes sont cliquables et ouvrent un détail sans quitter le cockpit. À droite de la carte, Tech affiche le Top des sites du jour et les sites réellement visités maintenant, à partir des données Stats AWM déjà collectées. Aucune identité de visiteur n’est exposée.

## Tech AWM 1.7.2 — carte globale alignée sur Stats

Le Centre d'opérations offre sept fenêtres temporelles (instant, 1 min, 1 h, 1 jour, 1 mois, 3 mois, 1 an) et affiche la courbe de visites directement sur la carte, sans fond de graphique opaque. Stats AWM reste la source de mesure et de GeoIP.

# Tech AWM 1.7.1 — Centre d’opérations Alliance


## Carte globale clients / sites

- Les points utilisent directement les localités GeoIP de présence de Stats AWM; Tech ne duplique pas le résolveur GeoIP et n’invente aucune coordonnée.
- Le payload conserve désormais `client_user_id + site_id` pour chaque point actif.
- Lorsque plusieurs clients/sites partagent une même localité, ils sont regroupés sous un seul point lumineux avec halo, puis listés séparément dans le popup.
- Le popup affiche le nom du client, le site, le nombre de visiteurs actifs et l’état HTTP courant du site.
- La carte conserve son zoom et son cadrage pendant les rafraîchissements silencieux de 30 secondes afin d’éviter tout flicker ou recentrage intempestif.

Tech AWM 1.7.1 poursuit le **Centre d’opérations AWM** avec une carte globale alignée sur la logique GeoIP déjà validée dans Stats AWM. La vue globale compile le parc canonique CRM/Connector et combine deux sources sans les confondre : Tech mesure disponibilité/temps de réponse/incidents, tandis que Stats AWM fournit trafic, visiteurs actifs, formulaires et localités GeoIP déjà collectées.

La sonde HTTP v1 travaille par lots de **12 sites toutes les 2 minutes** avec timeout de 4 secondes. Un premier échec ne déclenche pas immédiatement une panne : l’incident `http_unavailable` nécessite deux échecs consécutifs; la lenteur nécessite deux réponses successives à 2,5 s ou plus. Les sondes sont historisées 30 jours et les incidents restent conservés après résolution.

Le dashboard se rafraîchit silencieusement toutes les 30 secondes, conserve la carte Leaflet au lieu de la reconstruire et remonte automatiquement les lignes en anomalie. Le mode TV permet de garder la supervision ouverte sur un écran externe au bureau. Aucune valeur fictive n’est utilisée : un site jamais sondé reste `En attente` et un visiteur sans coordonnées GeoIP ne crée aucun point sur la carte.

**AWM Live Intervention n’est pas livré dans le runtime 1.7.1.** Il est inscrit au roadmap officiel comme prochaine évolution : le client pourra voir les changements sur son propre site et le curseur du technicien sans jamais voir Tech AWM, wp-admin, Elementor, les logs ou les secrets Alliance.

# Tech AWM 1.6.9 — contexte de développement complet

Tech AWM 1.6.9 conserve exactement le runtime multi-sites et l horloge Alliance de 1.6.8, mais complète le paquet avec une roadmap versionnée afin que les autres conversations puissent revoir la dernière publication avant de modifier Tech.

Aucun Connector, secret, `site_id`, `instance_uuid`, permission, télémétrie ou mécanisme d intervention n est modifié dans cette version.

# Tech AWM 1.6.7 — monitoring multi-sites par site_id

Tech AWM 1.6.7 rattache désormais la télémétrie et les interventions au Connector exact de chaque site. Un client peut conserver simultanément un principal, des sous-domaines et des WordPress en sous-répertoire sans que le dernier site ayant communiqué écrase le profil technique des autres installations.

Le monitoring par site couvre le profil WordPress/PHP/Elementor, les versions Hub Client et Tech, l inventaire logiciel, les mises à jour, les alertes, les vulnérabilités, le dernier contact et l identité `instance_uuid`. Les sessions d intervention vérifient également le `site_id` et le chemin canonique.

# Tech AWM 1.6.6 — parc client multi-sites

Tech AWM consomme maintenant la structure canonique CRM **Client → Site principal → Sites secondaires**. Le dashboard liste chaque URL comme un site distinct, conserve le rôle principal/secondaire, l’environnement et la source de design. Les sites non encore associés à un runtime Hub Client sont visibles comme **À connecter** au lieu d’être confondus avec le site principal.

# Tech AWM 1.6.5

## Monitoring central proactif — 1.6.5
Tech AWM 1.6.5 ajoute un cycle de surveillance central horaire sur Alliance et un rafraîchissement manuel des inventaires. Le scan automatique réévalue les vulnérabilités qui correspondent réellement aux versions présentes et journalise seulement les nouvelles correspondances critiques. Le bouton **Actualiser les inventaires** interroge directement les sites via le canal privé Hub Client afin de mettre à jour WordPress, plugins, thèmes, mises à jour disponibles et télémétrie Tech sans attendre une visite utilisateur.

Aucun fournisseur payant n est introduit : la source de vulnérabilités demeure Wordfence Intelligence V3 lorsqu une clé gratuite est configurée.


## Monitoring versions et vulnérabilités — 1.6.4
Tech AWM 1.6.4 fait progresser le centre d opérations Alliance : chaque runtime client remonte maintenant un inventaire borné de WordPress, des extensions et des thèmes avec les versions installées et les mises à jour proposées par WordPress. Le dashboard compare aussi les modules Suite AWM installés sur Alliance avec la publication active.

La section **Sécurité** ajoute un journal de vulnérabilités basé exclusivement sur **Wordfence Intelligence V3**, une source annoncée gratuite pour usage personnel et commercial. Depuis 2026, Wordfence exige une clé gratuite; elle est stockée dans le coffre Core côté Alliance et n est jamais distribuée aux sites clients. Tech télécharge le flux de façon centralisée, le met en cache et ne conserve que les avis qui correspondent aux logiciels présents dans le parc. Aucune API de vulnérabilités payante n est utilisée.

Tech ne signale pas simplement qu un plugin a déjà eu une CVE : il vérifie la **version réellement installée** contre les plages `affected_versions`, affiche le correctif connu lorsqu il existe et conserve l attribution de la source dans la vue sécurité.


## Apparence de la fenêtre — 1.6.3
Le panneau ⚙ sépare maintenant la transparence visuelle en deux réglages : **Fonds** (0–100 %) et **Texte + bordures** (25–100 %). La couleur d accent reste libre et un sélecteur de police permet de basculer entre Terminal moderne, Consolas, Courier New, Système premium, Arial et Georgia. Les changements sont instantanés et enregistrés uniquement dans le navigateur du technicien Alliance.

Tech AWM 1.6.3 conserve et renforce le mode **action-first** sur le frontend. Un titre sélectionné peut recevoir une nouvelle couleur même lorsque Tech ne peut pas résoudre son ID Elementor, grâce à une règle CSS de page strictement limitée et réversible. Le texte sélectionné peut aussi être rallongé, condensé, corrigé ou reformulé dans un ton plus formel/professionnel avant application.

Tech peut désormais demander une **génération d image côté Alliance**, importer le média généré dans WordPress et, lorsqu un widget image Elementor est explicitement sélectionné, proposer son remplacement. Le secret IA n est jamais envoyé au site client; la génération passe par le Connector privé et les écritures restent soumises aux permissions Alliance et au rollback.

# Tech AWM 1.6.1

Tech AWM 1.6.1 introduit le premier moteur d actions frontend réellement exécutable. Après sélection d un élément, l assistant doit préparer une action sûre au lieu d expliquer à l employé comment la faire dans Elementor. Les écritures restent explicites, réversibles et soumises à « Appliquer maintenant ».

Actions design prises en charge dans cette étape : texte/titres/boutons, couleurs, fonds, alignement, tailles de police ordinateur/tablette/mobile, marges et padding sur widgets/containers Elementor compatibles.

# Tech AWM 1.6.0

Tech AWM devient un centre d opérations Alliance orienté **frontend**. Le technicien lance **Intervenir sur le site**, navigue sur le vrai site client avec la fenêtre privée Tech persistante, sélectionne un élément et utilise le même moteur sécurisé d analyse, application et rollback. Elementor demeure disponible comme mode avancé.

Le dashboard principal est désormais source-first : navigation principale dans le menu WordPress à gauche, cartes/KPI cliquables, popups contextuelles et accès direct à la source exacte. Les indicateurs utilisent uniquement la télémétrie réellement disponible; aucune valeur d uptime, performance ou sauvegarde n est simulée.

# Tech AWM 1.5.13

Cette livraison stabilise le passage Alliance → Elementor. Le profil CRM n est plus utilisé comme seule preuve de version : Tech demande d abord un état live au site. Hub Client 1.11.29 peut générer le handoff sécurisé même lorsqu une ancienne classe Tech reste chargée dans la requête de mise à jour; Elementor charge ensuite la version Tech réellement présente sur disque dans une nouvelle requête PHP.

Cette version durcit le demarrage du runtime client et separe clairement les responsabilites : Hub Client expose le canal prive stable, Tech execute l intervention Elementor. Le runtime Tech peut etre reinitialise apres une mise a jour sans faire disparaitre l endpoint utilise par Core.

# Tech AWM 1.5.11

Cette version remplace le pont navigateur historique par un **handoff serveur direct vers Elementor**. Depuis Alliance, Core appelle le site Hub Client par son canal privé, Tech valide la session, résout le `post_id`, crée un handoff local à usage unique et retourne l URL `wp-admin/post.php?action=elementor`. La boîte Tech est donc préparée avant même que le navigateur entre dans Elementor.

Hub Client 1.11.25 complète ce parcours en invalidant OPcache après une mise à jour distante et en remontant la version Tech réellement chargée en mémoire. Core refuse de considérer Tech à jour si seul le fichier a changé mais que l ancien runtime PHP reste actif.


# Tech AWM 1.5.9


## Injection native Elementor — 1.5.9

La boîte d intervention Alliance est maintenant branchée directement sur les hooks officiels de l éditeur Elementor. Les hooks admin WordPress restent seulement en repli. Si un shell Elementor ne rend pas le footer WordPress attendu, le JavaScript Tech reconstruit l unique boîte à partir du markup de session déjà validé côté serveur. Aucun composant Tech n est rendu sans session Alliance valide.

## Préparation Elementor automatique — 1.5.8

Depuis 1.5.8, une intervention Elementor prépare automatiquement le runtime Tech du site client avec le paquet Tech de la publication active Core lorsqu une version plus récente est requise. La version distante est confirmée avant la création de session, puis Elementor s ouvre avec une seule boîte Tech privée.

## Horodatage Alliance — 1.6.8
Les événements Tech restent stockés en UTC. Dans l administration centrale Alliance, **Dernier contact** et les horodatages Tech concernés sont maintenant affichés avec le fuseau canonique `America/Toronto`, indépendamment du fuseau général WordPress. L heure normale et l heure avancée sont appliquées automatiquement. Lorsque Core AWM est chargé, Tech réutilise l horloge `AWM_Core_Time` afin que toutes les interfaces Alliance présentent la même heure.

## Intervention Elementor stabilisée
Tech AWM 1.5.6 garde une seule boîte privée dans Elementor et ajoute un préflight de disponibilité avant l ouverture. La boîte affiche la session active, attend automatiquement la prévisualisation Elementor, supporte les rechargements d iframe et rafraîchit l aperçu après une application ou un rollback sans multiplier les interfaces.

## Politique produit
Tech AWM reste un agent Alliance invisible dans Hub Client. Toute intervention, maintenance, santé, sécurité et réparation est pilotée depuis l administration Alliance.

## Architecture 1.5.1

Tech AWM est un agent privé Alliance installé silencieusement sur les sites clients. Aucune interface Tech n est exposée dans Hub Client. Les sessions d intervention front-end sont créées depuis Alliance, limitées au domaine/page, expirent automatiquement et utilisent le Connector existant pour validation serveur-à-serveur.
## Centre de santé et réparation Connector
Les diagnostics Connector, la santé WordPress/Elementor, la télémétrie et les actions de réparation sont réservés à Alliance. Tech AWM peut tester les quatre transports sécurisés, réparer la liaison, resynchroniser et purger les caches AWM ciblés sans exposer de secret ni d interface Tech dans Hub Client.

# Tech AWM 1.4.2 — Connector résilient

Le runtime client délègue désormais ses échanges Alliance au transport résilient de Hub Client.

# Tech AWM 1.4.1 — autorisation CRM/Connector renforcée

Tech AWM confirme maintenant son autorisation avec le même client_id CRM canonique que la fiche Alliance. Le transport Tech possède un mode compatible HTTPS pour les hébergements qui filtrent les en-têtes personnalisés, et Hub Client peut réparer automatiquement un ancien identifiant local à partir du Connector sécurisé.

# Tech AWM 1.4.0 — historique front-end contextuel

Cette version historique utilisait une fenêtre flottante sur une page WordPress/Elementor. Depuis Tech 1.5.x, l intervention est réservée à Elementor et aucune palette Tech n est rendue sur le front-end public. La page courante est transmise automatiquement; depuis Hub Client, une URL interne est résolue vers le `post_id` réel et devient la cible des actions et du rollback. Les conversations multi-tours utilisent le format OpenAI correct pour les réponses assistant.

# Tech AWM 1.3.0 — client_id CRM canonique

Tech ne possède aucune base clients. Toutes ses données sont rattachées au même `client_id` CRM, et l onglet Tech vit dans la fiche client CRM unifiée.

# Tech AWM 1.2.0

Tech AWM est le dixième paquet physique autonome de la Suite AWM.

Côté Alliance, Tech AWM utilise la fiche client canonique du Hub : l onglet **Clients** ouvre le moteur de recherche habituel, puis chaque fiche expose un nouvel onglet **Tech**. L activation centralisée, les permissions Chat / Diagnostics / Elementor / WordPress / Fichiers, les versions du runtime et le dernier contact sont gérés directement dans cette fiche.

Côté client, le paquet fournit uniquement le runtime silencieux nécessaire aux interventions Alliance. Aucun service, onglet, diagnostic ou palette Tech n est exposé dans Hub Client ni sur le front-end public.

- Le canal sécurisé existant de Hub Client reste utilisé.
- Installation et mises à jour exclusivement via Core AWM et le ZIP complet de la Suite.

## Liste centrale des sites Hub Client
Dans **Tech AWM → Sites**, Alliance voit automatiquement tous les sites dont Hub Client est confirmé par l’inventaire Core. La liste réutilise la fiche CRM canonique et permet de lancer une intervention directe sur le site lorsque Tech AWM est installé et autorisé. Les états Hub, Tech, santé, mises à jour, alertes, transport Connector et dernier contact sont visibles sans ouvrir chaque fiche.
## Navigation Alliance 1.5.2
Dans l’administration Alliance, **Tech AWM → Sites** est un onglet visible du shell commun. Ouvrir Tech AWM affiche directement cette liste afin que les techniciens puissent intervenir sans passer par CRM. La vue d’ensemble demeure accessible séparément.


## Éditeur Elementor — 1.5.3
Lorsqu’une intervention Alliance valide est active et que la page ciblée est ouverte avec Elementor, Tech AWM restaure la session dans `wp-admin`, affiche automatiquement la palette privée au-dessus de l’éditeur et relie le mode Inspecter à l’iframe de prévisualisation Elementor. Sans session Alliance temporaire valide, aucun composant Tech n’est injecté dans l’éditeur.


## 1.5.4
La Vue d’ensemble affiche maintenant directement la liste des sites Hub Client sur lesquels Alliance peut intervenir. L’onglet Sites demeure disponible pour la vue dédiée.


## 1.5.14 — Éditeur Elementor
La boîte Tech adopte une console monospace verte et n injecte plus de scripts dans `admin_head`; son chargement est retardé afin de ne pas interférer avec le bootstrap Elementor ni provoquer son écran de dépannage/Safe Mode.

## 1.5.15 — Lancement Elementor
Le bouton **Elementor** fournit maintenant un feedback immédiat et force proprement la soumission de la demande d'intervention après affichage du loader. Le technicien voit les étapes de préparation pendant que Core valide le site, Hub Client, Tech et la session privée Alliance.
## 1.5.16 — Safe Boot Elementor
La boîte Tech est désormais injectée seulement après l initialisation réelle d Elementor. Le runtime Tech reste passif pendant le bootstrap de l éditeur afin de ne pas contribuer au déclenchement du Safe Mode. L interface utilise le thème terminal Matrix premium validé par Alliance.


## 1.5.17 — preview Elementor isolé

L iframe `elementor-preview` est maintenant totalement exclue du bootstrap front-end Tech. Le cookie de session Alliance reste disponible pour la session privée, mais ne peut plus provoquer de redirection de la prévisualisation vers l éditeur. Cette séparation corrige la boucle de chargement qui déclenchait le panneau **Can t Edit? / Enable Safe Mode** pendant les interventions Tech.


## 1.5.18 — session persistante dans wp-admin
Une intervention lancée par Alliance reste visible lorsque le technicien navigue entre les écrans WordPress et l éditeur Elementor. La boîte utilise la même session temporaire, liée au client et à la page cible. Le réglage visuel permet de choisir la couleur terminale et l opacité totale de la fenêtre; ces préférences restent locales au navigateur Alliance.


## Carte compacte 1.7.17
La carte du Centre opérations n affiche plus de tuiles de sites ni de légende longue au-dessus du fond cartographique. Le compteur, les périodes et le bouton Moniteur sont regroupés dans l en-tête; les couleurs restent lisibles dans Top sites aujourd hui et dans les points/popups de la carte.


---

## ROADMAP.md

# Tech AWM 1.10.18 — Maintenant : validation Elementor depuis l'accès WordPress complet

- [x] Charger les droits du technicien dès `wp_loaded` aussi pendant `post.php?action=elementor`.
- [x] Autoriser la modification de toutes les pages permises par WordPress, sans confondre le scope admin et l'ancienne session limitée à une page.
- [x] Passage HTTPS apex/WWW à usage unique pour harmoniser l'origine de l'éditeur et de l'aperçu Elementor sans divulguer ni élargir le cookie administrateur.
- [x] Attendre la disponibilité réelle de l'aperçu avant d'afficher l'interface Tech dans Elementor.
- [x] Conserver les journaux, le rôle temporaire limité hors session et les 10 autres modules.
- [ ] Validation sur Couture Électro : depuis Monitoring → WordPress → Modifier avec Elementor, ouvrir l'éditeur, modifier une page TEST, contrôler le journal et la déconnexion.
- [ ] Si le chargement persiste, analyser les codes HTTP d'`admin-ajax.php`/REST, les erreurs PHP/Elementor et les éventuels conflits d'extensions avant de modifier la configuration.
- [ ] Contrôler l'affichage de cette étape sur la roadmap publique après publication; le manifeste local ne prouve pas la publication.

# Tech AWM 1.10.17 — Maintenant : journal des accès techniques, phase 1

- [x] Éliminer l'overlay Tech sur l'administration WordPress tout en préservant Elementor/frontend.
- [x] Ajouter la persistance SQL locale événement par événement pour les actions reconnues; migrer l'ancienne file sans perdre les événements déjà en attente.
- [x] Dédupliquer les relances vers Core AWM et assurer le cloisonnement par session d'intervention.
- [x] Afficher les événements centralisés dans **Tech AWM → Journal** avec recherche et pagination, en distinguant les simples requêtes des modifications détectées.
- [x] Prévoir la rétention locale configurable par code : 365 jours pour les lignes livrées, sans purge des événements non synchronisés.
- [ ] Test réel sur un site pilote : admin WordPress + Elementor + extensions + utilisateurs + retour hors-ligne.
- [ ] Ajouter une réconciliation vérifiable des anciennes sessions expirées lorsque la connexion centrale a été coupée.
- [ ] Envisager un journal indépendant au niveau serveur pour les opérations en dehors des hooks WordPress et les suppressions d'agent.
- [ ] Confirmer la publication du nouveau jalon dans la roadmap publique en ligne.

## Tech AWM 1.10.16 — Corriger le refus wp-admin (2026-10-12)
- [x] Revalider la session avant le chargement des menus WordPress (`wp_loaded`), avec fallback idempotent.
- [x] Conserver le rôle de base lecture seule ; accorder les capacités uniquement pendant une session centrale valide, liée au compte temporaire.
- [x] Isoler les identités frontend/Elementor et administration complète.
- [x] Contrôler les capacités et journaliser les refus sans cookies ni secrets.
- [x] Tests locaux (18 assertions).
- [ ] Tester sur un vrai site WordPress que « WordPress » ouvre la page d'accueil et que les menus Modules, Utilisateurs, Elementor fonctionnent.
- [ ] Vérifier la remontée des actions dans le journal Core/Tech en production.
- [ ] Vérifier l'affichage réel de cet avancement dans la roadmap publique.

## 1.10.15 — Stabilisation du moteur de contenu Elementor
- [x] Bloquer les `replace_text` non ciblés et limiter les modifications au sous-arbre Elementor sélectionné.
- [x] Envoyer au modèle les véritables widgets texte descendants d'une section (pas le conteneur seul).
- [x] Refuser l'écriture si Hub Client 1.14.20+ n'est pas installé sur le site.
- [x] Visualiser les nouvelles valeurs texte avant validation; conserver l'audit existant.
- [ ] Pilote sur un WordPress client réparé et validation de la précision de modification d'une seule section.
- [ ] Examiner les snapshots historiques douteux et restaurer le contenu original depuis les révisions valides.

# Tech 1.10.14 — phase de validation terrain (2026-10-12)

- [x] Administration WordPress temporaire active par défaut quand Tech et le client CRM sont actifs; exception de désactivation manuelle persistante et vérification côté serveur.
- [x] Ouverture du navigateur sans attente infinie : soumission synchrone d'un nouvel onglet, diagnostic visible dans celui-ci, délai de 20 secondes en navigation même onglet.
- [x] Précontrôle agent/permission; aucune mise à jour automatique silencieuse déclenchée par le bouton WordPress.
- [x] Tests de contrats PHP/JS des modes actif, inactif, désactivation volontaire, réactivation et ouverture immédiate.
- [ ] Valider en conditions réelles l'authentification sans mot de passe sur un site Tech >= 1.10.13, ainsi que le journal d'administration WordPress et l'ouverture des onglets sous Chrome.
- [ ] Publier et vérifier la roadmap sur https://alliancewebmarketing.ca/hub/roadmap/ (non confirmé depuis l'environnement de livraison).

# Tech AWM 1.10.13 — avancements 

- [x] Restaurer dans Monitoring les boutons **WordPress** et **Tech sur site**.
- [x] Accès admin WordPress temporaire sans mot de passe client, avec privilèges conditionnels (rôle de base lecture seule) et permission distincte désactivée par défaut.
- [x] Couvrir les principales modifications WordPress et Elementor avec un journal local et central lié au technicien et au site.
- [x] Préserver les tentatives d'audit hors ligne sans réattribution de session.
- [ ] Pilote réel : tester installation/suppression de plugins, Elementor, création/suppression d'un utilisateur et visibilité des logs, avec la permission activée uniquement pour le client pilote.
- [ ] Évaluer une couche d'audit indépendante de WordPress pour une conservation exhaustive en cas de désactivation du plugin.
- [ ] Confirmer la synchronisation visible sur la roadmap publique.

# Tech AWM 1.10.12 — Monitoring unifié et changements DNS confirmés

- [x] Fusionner les deux listes Monitoring existantes en un seul affichage par site.
- [x] Utiliser des cartes adaptatives avec recherche, filtres d'état, pagination et thème clair/sombre AWM.
- [x] Afficher les serveurs NS de la vraie zone DNS ainsi que les destinations A, AAAA et CNAME observées.
- [x] Montrer la zone surveillée, l'historique « avant/après » et la date d'un changement confirmé.
- [x] Envoyer un avertissement aux techniciens Tech après deux observations espacées de 30 minutes, sans notifier les clients finaux.
- [x] Éviter les faux avis au premier import DNS et lors du changement de schéma 1.10.11 → 1.10.12.
- [x] Conserver l'autorisation CRM active + Connector et la lecture seule.
- [ ] Vérifier l'affichage sur l'admin WordPress réel, mode sombre/clair et appareil mobile.
- [ ] Vérifier avec un domaine DNS pilote le courriel réel et les deux relevés depuis Alliance.
- [ ] Ajouter ultérieurement une seconde origine DNS indépendante pour vérifier propagation et incohérences géographiques.
- [ ] Confirmer la publication visible de ces avancements sur /hub/roadmap/ après import de la Suite.

# Avancement des idees Tech AWM (Suite 4.5.387)

**4 chantiers montes de Futur vers Maintenant (phase 1 installee / validation terrain attendue)** :

1. **SSL :** expiration, chaine non fiable, empreinte et seuils 30/14/7 jours — les alertes mailavancees restent a concevoir.
2. **DNS :** A, AAAA, NS, CNAME, MX, SPF, DMARC et difference confirmee — verification DKIM par selecteur et explications des impacts a venir.
3. **WP-Cron :** total, retard et anciennete, aucune argumentation des hooks exportee — detection precise d echec et remediation future.
4. **SQL :** poids des options autoload, metadonnees des tables — mesures de requetes lentes et optimisation manuelle a venir.

**16 autres idees** du paquet 4.5.386 restent en **Futur** sans changement. Les quatre chantiers ne deviennent pas 'termines' tant que les essais WordPress reels ne sont pas valides.

# Tech AWM 1.10.10 — périmètre des sites administrés

- [x] Ne pas confondre client actif et site géré.
- [x] Exiger client opérationnel CRM et Connector Hub Client authentifié, non révoqué.
- [x] Inclure les sites gérés mais hébergés ailleurs.
- [x] Exclure les URL purement commerciales (SEO/Ads/autres), les sites non appairés et les Connectors révoqués.
- [x] Sécuriser affichage, compteurs, Appliquer, Vérifier, règles globales et cron.
- [x] Conserver préférences et historiques lors de la disparition/reconnexion d’un site.
- [ ] Valider le périmètre réel des sites avec Hub Client sur l’installation Alliance.
- [ ] Mettre à jour la roadmap publique du Hub après le test terrain.

# Tech AWM 1.10.9 — Politique CRM : clients actifs seulement
- [x] Ne lister que les clients opérationnels du CRM dans Protection formulaires (exclure inactif/archivé/supprimé).
- [x] Aligner les compteurs de sites et de blocages sur ce seul périmètre actif.
- [x] Ne cibler aucun client inactif dans les actions manuelles ou programmées; vérifier à nouveau avant la requête distante.
- [x] Conserver les réglages historiques, y compris les synchronisations en attente, sans boucle cron sur des clients inactifs.
- [x] Réadmettre automatiquement les sites à la réactivation du client dans CRM; préserver les modes spécifiques.
- [x] Vérifier les 17 scénarios de contrat dans un harnais PHP local.
- [ ] Confirmer sur le Hub WordPress réel qu'un client inactif disparaît et revient à l'activation.
- [ ] Vérifier la propagation sur un site test actif avant déploiement généralisé.
- [ ] Publier la roadmap source sur /hub/roadmap/ lors de l'installation; non publiée à distance par ce build.

# Tech AWM 1.10.8 — UX harmonisée Protection formulaires
- [x] Utiliser les variables visuelles du shell partagé AWM (clair/sombre) pour les cartes, contrôles et états.
- [x] Corriger les libellés invisibles, sélecteurs trop foncés, et états à contraste insuffisant.
- [x] Remplacer les grandes cartes par une liste compacte responsive et pagination client-side.
- [x] Rechercher et filtrer les 80+ sites sans surcharge de requêtes au serveur.
- [x] Conserver les nonces, permissions et formulaires des actions par site; tests simulés.
- [x] Conserver Tech client 1.10.7 comme seuil compatible d’interventions; pas de redéploiement forcé pour une modification UI.
- [x] Préserver filtres et page après Vérifier/Appliquer depuis un même onglet.
- [x] Contrôles Chromium desktop / tablette / mobile, clair / sombre, sans débordement.
- [ ] Vérifier le rendu sur l'admin WordPress réel avec le thème AWM actif.
- [ ] Étudier une vue statistique agrégée 7/30 jours et un historique de blocage par formulaire.
- [ ] Publier la roadmap publique /hub/roadmap/ après mise en production; cette archive actualise les sources locales sans déployer directement sur le serveur.

# Tech AWM 1.10.7 — Monitoring HTTP / fiabilité des alertes
- [x] Supprimer les doubles probes immédiates comptées comme confirmation indépendante.
- [x] Espacer les preuves en passages WP-Cron; confirmation HTTP et transport distincte.
- [x] Traiter HTTP 403/429 comme ambiguïtés WAF/rate-limit, pas comme panne totale.
- [x] Prévoir une file prioritaire d'anomalies et préserver le roulement du parc.
- [x] Courriels de diagnostic complets, historique conservé 30 jours, anti-bruit 30 min.
- [x] Afficher la cause et l'heure du contrôle sur la fiche du site.
- [ ] Tester le déclenchement et la résolution d'incidents sur un WordPress réel (site pilote).
- [ ] Validation de l'impact des paramètres anti-bot/CDN et proxy sur les en-têtes de la sonde.
- [ ] Ajouter une seconde région indépendante pour confirmer une panne mondiale.
- [ ] Ajouter un bouton sécurisé « Tester la disponibilité maintenant » avec comparaison réseau.
- [ ] Mesurer la latence de traitement WP-Cron sur une flotte de 80+ sites.
- [ ] Publier le résumé sur /hub/roadmap/ (publication non confirmée depuis ce build).

# Tech AWM 1.10.6 — Anti-spam Elementor centralisé
- [x] Vue stagiaire en deux étapes : règle générale, puis sites / état / dérogations.
- [x] Contrôle local des formulaires avant Email/Email2, webhook et LeadTracker par Hub Client 1.14.19.
- [x] Déploiements site-scoped authentifiés par Core et confirmation de la version du mode appliqué.
- [x] Propagation asynchrone par lots, tentatives limitées, statut hors-ligne non trompeur.
- [x] Découverte quotidienne pour nouveaux sites et reprise des sites en échec.
- [x] Journal des commandes via AWM Core Security Log.
- [ ] Tester l'ensemble du flux en production sur un site pilote (Email, Email2, webhooks, LeadTracker, cache/CDN).
- [ ] Ajouter statistiques anti-spam sur plusieurs périodes et gestion d'exceptions par formulaire individuel.
- [ ] Couverture future Gravity Forms / Contact Form 7 via validation native avant notification.

# Tech AWM 1.10.5 — composant systeme par defaut
- [x] Actif par defaut pour tout client valide.
- [x] Désactivation uniquement par action humaine explicite en fiche CRM.
- [x] Aucun faux desactive si la resolution CRM est temporairement indisponible.
- [x] Core 4.5.262 installe/active/met a niveau Tech avant Recovery.
- [ ] Validation terrain sur Climat NordSud, Plomberie Soltech principal et Demenagement Hull.

# Tech AWM 1.10.3 — secours du canal Hub Client
- [x] Route REST minimale indépendante de Hub Client.
- [x] Authentification avec le secret de scan existant.
- [x] Réactivation limitée au plugin Hub Client canonique.
- [x] Aucune action générique d activation/installation exposée.
- [x] Compatible avec la reprise Core AWM 4.5.240.
- [ ] Déployer sur toute la flotte afin que les futures coupures Hub Client deviennent auto-réparables.

# Tech AWM 1.10.2 — automatisation de maintenance observable

## Livré
- Réveil immédiat quand une extension passe en Automatique.
- Inventaire frais avant décision de mise à jour.
- État du worker visible dans Avancé > Politique automatique des extensions.
- Compteur distinct `Bloquées Recovery` et conservation du fleet_state par site.
- Tech 1.10.1 / passage WordPress temporaire Elementor préservé.

## Maintenant
- Valider un site avec une mise à jour tierce et Recovery prêt.
- Valider un site non prêt : aucune écriture, mais une raison `Bloqué Recovery` claire.

## Ensuite
- Ajouter une action guidée `Préparer Recovery` depuis Tech quand une preuve manque, sans assouplir la garde automatique.

# Tech AWM 1.10.1 — authentification temporaire d intervention

## Livré — 2026-09-24
- [x] Passage **Elementor avancé** sans écran `wp-login.php` lorsque le technicien Alliance n est pas déjà connecté au WordPress client.
- [x] Handoff à usage unique, expirant, relié à la session Tech validée et à la page exacte.
- [x] Utilisateur WordPress temporaire à capacités d édition limitées; aucun mot de passe transmis ou affiché.
- [x] Cookie WordPress limité à la durée restante de la session Tech et suppression automatique du compte temporaire.
- [x] Même authentification temporaire pour une intervention frontend nécessitant `current_user_can(edit_post)`.
- [x] Conservation des gardes site/client/instance/domaine et du moteur de snapshot/rollback.
- [ ] Maintenant : valider Canevas Rive-Sud puis un deuxième site pilote; Elementor doit s ouvrir directement et les actions Tech doivent conserver le nonce REST WordPress.
- [ ] Ensuite : afficher dans la chronologie Tech l ouverture/expiration de la session WordPress temporaire et le nettoyage du compte.

# Tech AWM 1.10.0 — UX guidée des mises à jour

## Livré
- Parcours en trois niveaux : **À faire maintenant / Installer / Avancé**.
- Regroupement des mises à jour par site avec une action principale claire.
- Détails des extensions repliés par défaut.
- Sites à jour regroupés dans une section secondaire.
- Sélecteur unique du site de destination pour les installations.
- Séparation visuelle des modules AWM et du catalogue WordPress approuvé.
- Zone avancée pour les politiques globales, l'inventaire complet et les versions de la Suite.
- Responsive spécifique au centre de mises à jour.

## Maintenant
- Valider le parcours avec un stagiaire : ouvrir Mises à jour, identifier un site, lancer **Mettre à jour ce site**, puis vérifier le résultat.
- Tester l'installation d'un module AWM avec le nouveau sélecteur unique de destination.
- Vérifier desktop, tablette et mobile sans perte d'action importante.

## Ensuite
- Ajouter une recherche rapide par client/site dans **À faire maintenant** si la flotte dépasse environ 30 sites.
- Ajouter un historique simplifié par site : dernière mise à jour, résultat, rollback éventuel.
- Ajouter un badge de niveau de protection par extension (Recovery complet / secours borné / manuel requis).

# Tech AWM 1.9.4 — mises à jour tierces / premium protégées
## Livré
- Canal direct Tech → Core → Hub Client pour les mises à jour tierces.
- Support des paquets premium fournis par le site, dont Elementor Pro.
- Statuts de rollback/review_required traités comme échecs réels.
## Maintenant
- Pilote Allo Déménagement : Elementor Pro → Mettre à jour protégé → inventaire frais → Elementor fonctionnel.
- Tester ensuite `Mettre à jour les X` sur un site pilote avec deux extensions tierces.
## Ensuite
- Badge de niveau de protection par extension.
- Approbation Recovery des cibles automatiques depuis Tech sans édition manuelle de config privée.

# Tech AWM 1.9.3 — session active et réécriture fiable

## Livré
- Session glissante 20 min d inactivité, plafond 4 h par intervention.
- Réécriture déterministe des champs texte sélectionnés : SEO, reformulation, longueur, ton et correction.
- Les actions restent set_setting, permissionnées, SHA-256 contrôlées, snapshotées et rollbackables.

## Maintenant
- Allo Déménagement : laisser la session ouverte >20 min avec activité, puis confirmer qu elle reste active.
- Tester heading : texte SEO, reformuler, plus long, plus court → Appliquer → Rollback.
- Reprendre ensuite container/colonne/image de Tech 1.9.0.

# Tech AWM 1.9.2 - transport REST meme site

## Livre
- Resolution du REST sur l origine navigateur pour les alias `www` / apex canoniquement equivalents.
- `credentials: include` + `X-WP-Nonce` sur tous les clients REST Tech, incluant le panneau sante.
- Conservation stricte de `edit_post`, site_id, instance_uuid et session Alliance.

## Maintenant
- Allo Demenagement : ouvrir l admin sur `allodemenagement.ca`, lancer Elementor alors que la cible canonique est `www.allodemenagement.ca`, puis verifier **Session connectee**.
- Tester texte, container et retour frontend, avec Appliquer puis Rollback.

# Tech AWM 1.9.1 - continuité de session frontend / Elementor

## Livré
- Nonce REST WordPress injecté dans la configuration de session Tech.
- `X-WP-Nonce` envoyé sur tous les appels REST Tech.
- Passage frontend → Elementor → frontend sans perte du `current_user`.
- Aucune réduction des contrôles `edit_post`, site_id, instance_uuid ou session Alliance.

## Maintenant
- Valider Allo Déménagement : intervention frontend → Modifier avec Elementor → action container/texte → retour frontend.
- Confirmer qu un utilisateur WordPress non autorisé reste refusé.

# Tech AWM 1.9.0 - moteur Elementor généralisé

## Livré
- Sélection et modification des containers, sections et colonnes.
- Réglages layout sûrs : largeur/min-height, flex, alignement, gap, overflow, espacements, fond, bordures, z-index et visibilité responsive.
- Widgets natifs enrichis : texte, image, icône, divider, spacer, image/icon box, testimonial, counter, progress et Google Maps.
- Fallback IA ciblé universel sur l élément sélectionné.
- Photos : remplacement du widget image ou de l image de fond par action réversible.

## Maintenant
- Pilote Allo Déménagement : texte plus long/reformulé, container padding/fond/flex, colonne largeur, image et background image.
- Appliquer puis Rollback chaque famille avant flotte.

# Tech AWM 1.8.6 - intervention texte selectionne

## Livre
- Reecriture fiable d un widget texte selectionne avec fallback specialise si le premier passage ne retourne aucune action.
- Action toujours reversible et soumise aux permissions Elementor + SHA de page.
- Icone Reglages visible dans la fenetre Frontend.

## Maintenant
- Valider Allo Demenagement: meilleure description -> proposition -> Appliquer -> Rollback.
- Verifier heading, text-editor et button sur un second site.

## Ensuite
- Etendre le meme moteur cible aux images, CTA et styles avec actions explicites.
- Afficher les metriques de latence/tokens et les causes de rejet d action dans la fiche intervention centrale.

# Tech AWM 1.8.5 — conversation distante fail-closed

## Livré maintenant
- Restauration de `remote_status()` et `has_permission()` dans le runtime d intervention.
- Vérification explicite de la classe/méthode distante avant appel et capture `Throwable`.
- Refus propre en `WP_Error` si Alliance ne retourne pas un état structuré ou si Tech est désactivé.
- Garde de permissions commune pour chat, fichiers, écriture Elementor et actions techniques.

## Maintenant
- Rejouer Allo Déménagement : sélectionner le même widget → demander une meilleure description → vérifier proposition → Appliquer → Rollback.
- Confirmer qu aucune exception `remote_status` / `has_permission` n apparaît dans Diagnostic.

## Ensuite
- Ajouter un test de régression automatique sur les appels `self::...()` sans méthode correspondante avant chaque ZIP Tech.
- Continuer la validation canari de l autopilote séparément du chat Tech.

# Tech AWM 1.8.4 - chat Elementor cible et diagnostic exploitable

## Livre maintenant
- Lecture directe du widget Elementor selectionne dans `_elementor_data` pour eviter de charger toute l arborescence lors d une demande simple.
- Contexte IA reduit au widget, champs editables et hash de document.
- Pipeline chat trace par etapes et erreur PHP exacte visible dans la fenetre privee.
- Diagnostic affiche la derniere erreur Tech avec code, etape et message.

## Maintenant
- Rejouer Allo Demenagement : selectionner le meme bloc puis demander une meilleure description.
- Si une erreur subsiste, relever directement l etape et le message affiches; aucune nouvelle supposition ne sera necessaire.
- Verifier proposition, Appliquer maintenant et Rollback.

## Ensuite
- Journaliser latence/taille de contexte de chaque demande Tech.
- Conserver les actions et erreurs dans la fiche intervention centrale.

# Tech AWM 1.8.3 - intervention frontend stabilisee

## Livre maintenant
- X ferme reellement la grande fenetre et conserve un lanceur Tech AWM compact.
- Une seule instance du panneau peut etre attachee a une surface.
- Chat sur element selectionne : contexte minimal du widget + champs editables, sans inventaire logiciel complet.
- Messages d erreur exploitables + journal Tech pour les erreurs IA/Connector/chat.

## Maintenant
- Rejouer sur Allo Demenagement : selectionner un texte, demander une meilleure description, verifier la proposition puis Appliquer et Rollback.
- Verifier fermeture X, reouverture par le lanceur et navigation sur plusieurs pages.

## Ensuite
- Ajouter un indicateur de taille/contexte et de latence de chaque demande Tech.
- Rendre les conversations et actions visibles dans la fiche intervention centrale avec leur code d erreur exact.

# Tech AWM 1.8.2 — navigation d intervention connectée

## Livré
- Fenêtre Tech persistante sur le frontend pendant la navigation du même site.
- Session toujours protégée par connexion WordPress + droits d édition + session Alliance valide.
- Page courante automatiquement utilisée comme contexte/cible quand elle est éditable.
- Fermeture/réouverture de la fenêtre sans couper la session.
- Conservation du fil de conversation pendant la navigation de la session navigateur.

## Maintenant
- Valider Allo Déménagement : Elementor avancé → frontend → naviguer sur 3 pages → sélectionner un élément → revenir dans Elementor.
- Confirmer qu un navigateur non connecté ne voit jamais la fenêtre Tech.
- Confirmer principal et site secondaire séparément.

## Prochaines étapes
- Ajouter un bouton explicite **Terminer la session** distinct du simple bouton Fermer.
- Journaliser les changements de page dans AWM Live Intervention (`page_changed`) avec durée par page.
- Conserver éventuellement l historique visuel du chat lors des navigations, en plus du `thread_id`.

# Tech AWM 1.8.1 — handoff Elementor / intervention canonique

## Livré
- Normalisation sûre `www` / apex pour le même site jumelé.
- Respect strict du `site_id`, de l `instance_uuid`, du port HTTPS et du sous-répertoire WordPress.
- Refus des chemins ambigus/traversal avant ouverture d une session d intervention.

## Maintenant
- Rejouer **Elementor avancé** sur Allo Déménagement principal puis sur un secondaire.
- Confirmer que l URL d éditeur retournée reste dans le même site et le même répertoire.
- Conserver le rollback et l audit de session avant d élargir les actions d intervention.

# Tech AWM 1.8.0 — gestionnaire central de modules AWM

## Livré
- Nouvelle bibliothèque **Modules AWM** séparée de la bibliothèque WordPress.org.
- Sélection d une cible exacte `client_id + site_id` et déploiement via l autorité Core.
- Version/paquet/hash impossibles à substituer depuis Tech.
- Vérification d inventaire après installation et message spécifique si la cible est déjà à jour.
- Badge Hub Client **MU protégé / MU à vérifier** dans la vue Sites.

## Maintenant
- Après publication Suite 4.5.253, migrer un seul Hub Client pilote vers 1.12.0 MU.
- Depuis Tech, confirmer le catalogue renvoyé par Core puis tester une installation/réparation sur le même pilote.
- Vérifier Accès au site et Elementor après chaque opération avant d étendre la flotte.

## Futur — bibliothèque de modules
- Ajouter de nouveaux modules clients par politique explicite Core sans devoir modifier le moteur Hub Client pour chaque slug.
- Afficher dépendances, compatibilité PHP/WordPress et préflight par module avant installation.
- Installation groupée multi-sites avec bilan indépendant et rollback par site.

## Futur — Recovery MU
- Faire surveiller loader, config et runtime Hub Client par Recovery hors WordPress pour couvrir aussi la suppression physique du MU-loader.

# Tech AWM 1.7.40 — activation sûre en processus propre

## Livré
- Sandbox d activation ultra-léger sous `WP_SANDBOX_SCRAPING`.
- Aucun runtime Tech/Elementor pendant l activation WordPress.
- Activation distante orchestrée dans une requête distincte par Hub Client 1.11.51.

## Maintenant
- Allo Déménagement : confirmer Tech 1.7.40 actif, puis Accès au site et Elementor.
- Valider ensuite un deuxième site pilote avant toute flotte.

# Tech AWM 1.7.39 — stabilisation du bootstrap client

## Livré
- Bootstrap client différé pour ne plus faire tomber `update/status` après remplacement à chaud de Tech.
- Garde anti-doublon sur les classes Tech client/central.
- Capture locale du dernier bootstrap fatal/Throwable sans exposer de chemin absolu à Alliance.

## Maintenant
- Rejouer le pilote Allo Déménagement : Tech 1.7.34 → 1.7.39 après Hub Client 1.11.50.
- Après succès, ouvrir **Accès au site** puis une session Elementor pour confirmer le runtime fonctionnel, pas seulement la version installée.
- Si `awm_tech_boot_error` est alimenté, remonter son message nettoyé dans Voir avant toute flotte.

## Futur
- Ajouter une sonde de bootstrap Tech dédiée dans Hub Client et un rollback local automatique si la sonde fonctionnelle échoue après activation.

# Tech AWM 1.7.38 - Suite 4.5.243

## 1.7.38 — Accès au site manuel compatible Recovery suspendu — 2026-09-22
- Le clic administrateur **Accès au site** est maintenant traité comme une intervention manuelle explicite.
- Si Hub Client ou Tech doit être préparé avant l ouverture de la session, Tech appelle Core avec `manual=true` et le `site_id` exact.
- Le chemin manuel conserve canal signé, SHA-256, sauvegarde/rollback fichiers et vérification de version.
- L autopilote reste suspendu et aucun déploiement implicite ne contourne Recovery.
- Correction pertinente après migration d hébergement : une preuve RESTORE_TEST peut être invalide sur la nouvelle topologie, sans empêcher une intervention manuelle protégée.

# Tech AWM 1.7.37 - Suite 4.5.235

## Livré dans 4.5.235
### 1.7.37 — Etat Recovery exploitable par le Tech — 2026-09-15
- Les cartes Recovery du parc distinguent route de secours, périmètre de sauvegarde et vrai test de restauration.
- `Recovery prêt` ne signifie plus que l'URL répond : l'interface montre explicitement si l'automatisation reste interdite.
- Aucun changement de privilège : un Tech AWM reste administrateur par défaut, avec restrictions explicites possibles.

Date : 2026-09-15

## Livre dans le code candidat

Boutons Recovery relies aux identites nominatives via Core, acces aux portes clientes deja verifiees meme si WordPress est maintenant indisponible. Moteur de mise a jour protege sur version cible exacte et suivi de resultats. Bibliotheque centrale accessible depuis Core.

## Validation terrain requise

Candidate de stabilisation. Aucun deploiement effectue. Recette reelle WordPress + MySQL/MariaDB + PHP-FPM/OPcache + HTTPS et watchdog systeme obligatoire avant activation. Autopilote Suite AWM toujours suspendu. Les paquets des nouvelles mises a jour tierces proviennent encore du fournisseur WordPress de chaque site; leur telechargement unique depuis Alliance reste au roadmap.

## Prochaines etapes

Telechargement central des mises a jour fournisseurs avec droits/licences par site; restauration depuis une archive Alliance absente localement; ordonnanceur et politique editables dans UI; purge physique des objets orphelins apres verification des references; tests visuels/metier et MFA de secours. Les signatures de fournisseurs ne sont pas remplacees par les seules empreintes SHA.

## Roadmap anterieure conservee

# Tech AWM 1.7.35 — Recovery du parc

## Livre
- Bouton Recovery dans le shell Tech et sous-menu de supervision.
- Lien direct vers Recovery central et vers chaque Hub Client qui annonce sa porte de secours.
- Statut Recovery/agent CLI visible par site sans exposer les chemins prives.
- Le catalogue WordPress deja remonte par Hub Client reste la source de vue globale; Recovery conserve ses propres cinq archives par extension.

## Validation terrain
- Tester un site joignable, puis couper volontairement WordPress et confirmer que l URL Recovery conservee dans Tech reste utilisable.
- Valider le parcours Tech niveau 1 : logs -> module probable -> timeline -> dernier stable -> verification.
- Confirmer qu une URL Recovery hors domaine attendu est rejetee par Core.

## Futur apres validation
- Resume de sante Recovery dans le Morning Brief sans executer de restauration automatiquement.
- Alertes de retention/quota et preuve de derniere restauration testee par site.

# Tech Awm 1.7.34 — Morning Brief Health transversal

## Livré
- Le Brief AWM affiche le score Health Suite /100 et ses raisons de vigilance tout en conservant incidents, SLA et priorités comme autorités opérationnelles.
- Le score Health est rafraîchi avec le snapshot du cockpit et reste strictement informatif.

## Prochain lot accéléré
- Corrélations Health par client/site entre incidents, Stats, tickets et CRM.
- Tournée Tech enrichie par fraîcheur et capacité, sans réaffectation automatique.

# Tech AWM 1.7.33 — Pulse opérationnel transversal

## Livré
- Expose au Core un pulse incidents ouverts / critiques afin d alimenter la santé système transversale.
- Le pulse est en lecture seule et ne remplace pas les préflights, actions recommandées ou preuves Tech.

## Prochain lot accéléré
- Morning Brief transversal basé sur les pulses Core, avec corrélations par client/site.
- Croiser incidents, fraîcheur Stats, tickets et état CRM avant de suggérer une tournée ou une action.

# Tech AWM 1.7.32 — feuille de route

## Tech AWM 1.7.32 — livré maintenant
- [x] Préflight Connector / permissions / OPcache visible dans chaque fiche Tech avant intervention.
- [x] Tournée Tech suggérée regroupée par client + site dans Incidents.
- [x] Vue de capacité par responsable avec non assigné, ancienneté, SLA et score maximal.
- [x] Aucun chemin serveur, secret ou réaffectation automatique ajouté au payload.

## Maintenant — validation terrain
- [ ] Comparer un site avec Connector sain, un site avec permissions d écriture limitées et un hébergement OPcache sans validation des timestamps.
- [ ] Vérifier qu une tournée regroupant plusieurs incidents du même site ouvre toujours la bonne fiche `client_id + site_id`.
- [ ] Comparer la charge de deux comptes Tech et confirmer que Non assigné, SLA à risque/dépassé et ancienneté restent cohérents.

## Prochain lot accéléré
- [ ] Préflight rafraîchissable à la demande avant intervention sans recharger tout le cockpit.
- [ ] Préparer les actions semi-automatiques uniquement lorsqu un snapshot/rollback fiable est prouvé pour le type d action.
- [ ] Ajouter des fenêtres de maintenance et une tournée assignable sans réaffectation automatique.
- [ ] Historiser la capacité Tech pour tendances 24 h / 7 j sans dupliquer Health.


## Livré
- Score impact × urgence × confiance sur les incidents, visible et explicable.
- File d actions recommandées par incident avec accès aux surfaces Tech pertinentes.
- Historique fiche Tech 24 h / 7 j, basé sur les événements existants sans recopier Stats.

## Maintenant
- Valider sur incidents HTTP, sécurité, lenteur et Connector.
- Vérifier que les historiques 7 j restent rapides sur un parc réel.

## Prochain lot accéléré
- Préflights Connector / permissions / OPcache avant intervention distante.
- Regroupement multi-incidents par client et suggestion d ordre de tournée Tech.
- Actions semi-automatiques seulement lorsqu un snapshot/rollback sûr existe.

# Tech AWM 1.7.31 — accélération opérations et observabilité

- **Livré** : filtres Client et Site dans les fenêtres Priorités du parc et Incidents, en plus des filtres criticité/signal/workflow; les choix restent mémorisés pendant la session.
- **Livré** : les sites avec incident ouvert passent en priorité dans chaque lot de sondes, sans dépasser la limite globale de 12 sondes par cycle; le round-robin normal continue pour le reste du parc.
- **Livré** : Wordfence Intelligence conserve les 12 dernières tentatives de synchronisation sans secret, mémorise le dernier succès et classe la fraîcheur en Données fraîches / Cache acceptable / Données périmées / Jamais synchronisé.
- **Livré** : la page Sécurité affiche dernier succès, dernière tentative et historique de synchronisation avec statut HTTP utile.
- **Gouvernance** : roadmap, changelog, notes de livraison et validation sont synchronisés avec Suite AWM 4.5.227.

## Tech AWM 1.7.29 — diagnostic Wordfence V3 clair et non bloquant

- Le refus Wordfence Intelligence n ouvre plus une fenêtre globale bloquante : l état apparaît directement dans le panneau Sécurité et le reste de la page demeure utilisable.
- Un HTTP 401 est identifié explicitement comme **clé Wordfence Intelligence V3 refusée** et explique que la clé doit provenir de **Wordfence > Account > Integrations**, pas de la licence du plugin Wordfence installée sur un site.
- Le panneau propose **Retester maintenant**, **Configurer la clé** et **Wordfence Integrations** sans exposer le secret et sans distribuer la clé aux sites clients.
- Le KPI Journal gratuit distingue désormais **Actif**, **Clé refusée**, **À vérifier** et **À configurer** au lieu d afficher Actif dès qu un secret existe.
- Les erreurs 429, réseau ou réponse invalide restent non bloquantes et conservent le dernier diagnostic utile; aucun faux résultat de vulnérabilité n est inventé.
- Le bloc de diagnostic suit la typographie personnelle Tech et reste responsive.
- ROADMAP, CHANGELOG, notes de livraison et rapport de validation sont synchronisés avec la version.

## Tech AWM 1.7.28 — alertes actionnables, overlays lisibles et Moniteur personnalisable

- Toutes les annotations de **Priorités du parc** liées à un site sont maintenant entièrement cliquables, pas seulement les situations corrélées : cliquer n importe où sur une ligne ouvre la fiche Tech complète du site.
- La fiche ouverte depuis une alerte fournit le résumé technique existant et ses actions contextuelles : ouverture du site, détails techniques, contrôles, Connector, mises à jour ou autres actions déjà autorisées selon l état réel du site.
- Les lignes cliquables affichent un indice visuel et une indication **Cliquer pour le résumé complet et les actions**; les actions sensibles conservent leurs confirmations et permissions existantes.
- La **Typographie dashboard** personnelle s applique désormais aussi aux fenêtres Tech, notamment **Priorités du parc**, filtres, annotations, résumés, historiques, boutons d intervention et fiches site ouvertes en overlay.
- Le **Mode moniteur** utilise maintenant le même moteur de personnalisation de blocs que le dashboard : visibilité, ordre, drag & drop, grille 12 colonnes et largeurs 1/4, 1/3, 1/2, 2/3, 3/4 ou pleine largeur.
- La disposition du Moniteur est indépendante de celle du dashboard et reste enregistrée par `user_id`; un Tech peut donc construire un écran mural différent de son poste de travail.
- La **Typographie Moniteur** conserve la priorité en Mode moniteur, y compris lorsque les blocs sont redimensionnés ou déplacés.
- ROADMAP, CHANGELOG, notes et rapports de validation sont synchronisés avec cette livraison.

## Tech AWM 1.7.27 — édition de grille sans panneau superposé

- Quand le Tech choisit le préréglage **Personnalisée**, le panneau de personnalisation se ferme automatiquement afin de rendre tout le dashboard disponible pour le drag & drop.
- Un bouton **Déplacer les blocs** permet aussi d entrer directement dans ce mode lorsque la disposition enregistrée est déjà personnalisée.
- Pendant le déplacement, une barre compacte reste en bas de l écran avec **Annuler** et **Enregistrer mon tableau**; le panneau flottant ne masque plus la carte ni les autres blocs.
- Ouvrir de nouveau l icône Personnaliser met le déplacement en pause sans perdre la disposition de travail; fermer le panneau sans sauvegarder restaure les préférences enregistrées.
- Les raccourcis, blocs visibles, typographie, profils 1080p/4K, grille 12 colonnes et responsive interne restent sauvegardés par `user_id`.

## Tech AWM 1.7.26 — dropdown de liens, blocs container-responsive et typo des fiches

- `Liens personnalisés` devient un dropdown compact directement dans la zone d actions de l en-tete Tech, avant Personnaliser et Light/Dark; les raccourcis ne consomment plus de largeur en permanence.
- `Fermer` du panneau Personnaliser devient un vrai bouton compact avec icone, cohérent avec le reste du shell.
- La Carte utilise maintenant la largeur réelle de son bloc : les périodes se réorganisent en 4 puis 2 colonnes au lieu de déborder sur le bloc voisin.
- `État des sites` abandonne le défilement horizontal lorsque la colonne devient insuffisante : chaque ligne se transforme automatiquement en carte avec libellés, puis en pile verticale sur les petites zones.
- Les blocs étroits utilisent des container queries : la décision de passer en mode compact dépend de la largeur du bloc 1/4, 1/3, 1/2, etc., pas seulement de la largeur globale du navigateur.
- La **Typographie dashboard** personnelle suit maintenant aussi la fiche Tech, ses onglets, métriques, SEO, WordPress, sécurité, historique, boutons et cartes de sites; l échelle reste propre à chaque `user_id`.
- Les préférences par `user_id`, la grille 12 colonnes, les ratios, le drag & drop, les profils 1080p/4K et les données de monitoring restent inchangés.

## Tech AWM 1.7.25 — en-tete compact et dropdown Dark

- Les raccourcis personnels quittent la grande barre sous le shell et sont maintenant injectes directement dans l en-tete Tech, a cote du contexte du module.
- Le bouton Personnaliser devient une icone compacte placee immediatement a gauche du bouton Light/Dark; la rangee supplementaire du dashboard est supprimee.
- Les raccourcis restent propres a chaque `user_id`, defilent horizontalement si l espace devient trop etroit et ne forcent plus une carte pleine largeur en hauteur.
- Le dropdown Prereglage et tous les selects du panneau Personnaliser utilisent maintenant un schema de couleur natif coherent en Dark et Light; les options ne peuvent plus apparaitre blanc sur blanc.
- Aucun changement au moteur grille 12 colonnes, aux ratios, au drag & drop, aux donnees de monitoring ni aux Connectors.

## Tech AWM 1.7.24 — grille responsive personnalisable

- Le dashboard utilise maintenant une grille 12 colonnes avec ancrage automatique et largeurs 1/4, 1/3, 1/2, 2/3, 3/4 ou pleine largeur.
- Chaque Tech peut déplacer les blocs directement en mode Personnaliser; le drag & drop réordonne la grille sans positionnement libre au pixel près.
- Chaque bloc conserve sa largeur et son ordre par `user_id`; un Tech peut donc afficher Visites verticalement en 1/3 tandis qu un autre l affiche horizontalement en 3/4.
- Les blocs changent leur présentation interne selon leur largeur : Top sites peut s étaler sur deux colonnes, KPI se recompone, Timeline et Carte deviennent compactes lorsque leur zone est étroite.
- Pour les paires Carte/Visites et Timeline/Incidents, une largeur 3/4 ajuste automatiquement le compagnon à 1/4 (et 2/3 à 1/3) lorsque les deux blocs sont voisins, afin de remplir proprement la rangée.
- Le responsive protège la mise en page : ratios personnels conservés sur bureau/1080p/4K puis empilement automatique lorsque l écran devient trop étroit.
- La taille de typographie personnelle est appliquée aussi aux textes secondaires du dashboard afin d éviter les éléments qui restent minuscules.
- Un bouton Réinitialiser la grille restaure la disposition AWM standard 2/3 + 1/3.

## Tech AWM 1.7.23 — flotte, bibliothèque et dashboard personnel

- Gestion globale Automatique/Manuel des extensions tierces actives et bouton Tout mettre à jour avec confirmation succès/échecs.
- Boutons de mise à jour harmonisés au CSS des autres actions Tech.
- Bibliothèque AWM initiale d extensions WordPress.org approuvées, installables à distance sur un site Hub Client connecté.
- Dashboard personnalisable par utilisateur Tech : blocs visibles, raccourcis personnels, disposition Standard/Carte en premier/Sites en premier, taille de typo réglable finement, profil Moniteur Auto/1080p/4K et taille Moniteur.
- Préférences enregistrées par utilisateur via AJAX, sans rechargement de page.
- La roadmap publique reste obligatoire et synchronisée avec la publication Suite active.

# Tech AWM 1.7.22 — Moniteur cast + UX sans rechargement

- [x] Ajouter un bouton **Économiseur** pour un démarrage immédiat en Mode moniteur.
- [x] Fiabiliser l inactivité avec Chromecast et ignorer les micro-mouvements pointeur parasites.
- [x] Ne plus bloquer l économiseur quand une critique existe déjà; réveiller seulement sur nouvelle critique.
- [x] Rafraîchir une fiche site par AJAX sans retour en haut de page.
- [x] Mettre à jour une extension WordPress par AJAX puis rafraîchir la fiche.
- [x] Ajouter **Mettre à jour les X** avec progression séquentielle et inventaire final unique.
- [x] Enregistrer les réglages Mode moniteur sans rechargement complet.

## Livré
- [x] Appliquer à tous les formulaires Réglages le CSS lisible du Mode moniteur.
- [x] Uniformiser cartes, champs, selects, textes d aide et boutons Enregistrer.
- [x] Conserver le sticky uniquement pour l action Moniteur.
- [x] Maintenir une grille responsive à une colonne sur petits écrans.

# Tech AWM 1.7.20 — fiche multi-sites actionnable

- [x] Rendre À connecter cliquable vers le Connector exact du site_id.
- [x] Rendre À vérifier cliquable et relancer le diagnostic lorsque le runtime est disponible.
- [x] Conserver le retour sur la fiche du site après une vérification manuelle.
- [x] Aligner Vérifier maintenant et Ouvrir le site sur une hauteur commune.


## Livré
- Fiches techniques séparées pour principal et secondaires avec URL complète.
- Vérification WordPress/SEO immédiate à la demande.
- Mise à jour manuelle d une extension tierce directement depuis la fiche.
- Sauvegarde Mode moniteur fiabilisée et CSS de listes/réglages rendu lisible.

## Maintenant
- Valider sur un client multi-sites et sur une extension tierce avec mise à jour disponible.
- Confirmer l activation réelle de l économiseur après sauvegarde.

# Tech AWM 1.7.18 — Mode moniteur + économiseur

**Livré :** Mode moniteur débarrassé du shell et des blocs de contexte, typographie plus grande, thème repositionné dans la barre carte et économiseur intégré au navigateur avec réveil sur Critique.

**Maintenant :** caster la fenêtre Moniteur plusieurs heures et valider lisibilité, activation/sortie de l économiseur et réveil critique sur un site de test.

**Prochaines étapes :** profils Moniteur enregistrables par écran et rotation optionnelle entre plusieurs tableaux métier sans dupliquer les données.

# Tech AWM 1.7.17 — carte Centre opérations compacte

**Livré :** suppression des deux rangées de légende au-dessus de la carte; périodes, compteur et Moniteur sont regroupés dans l’en-tête. La carte gagne en hauteur et Top sites aujourd’hui porte la correspondance couleur opérationnelle.

**Maintenant :** valider à 1366 / 1440 / 1920 px et en fenêtre Moniteur que la barre reste sur une ligne lorsque l’espace le permet et que la carte utilise bien la hauteur récupérée.

**Prochaines étapes :** filtres Client / Site du Centre opérations sans réintroduire de rangée permanente au-dessus de la carte.

# Tech AWM 1.7.16 — fiche Tech console opérationnelle

## Livré
- [x] En-tête de fiche compact et actionnable avec rôle, URL, score, disponibilité et indexation.
- [x] Barre Santé du site avec seulement les métriques utiles à la décision.
- [x] Zone À faire qui priorise erreurs, no-index, vulnérabilités, alertes, mises à jour et Connector stale.
- [x] Onglets Vue d’ensemble / SEO / WordPress / Sécurité / Historique.
- [x] Vue d’ensemble en trois blocs compacts : Santé technique, SEO essentiel, WordPress & maintenance.
- [x] Filtres d inventaire WordPress : Tous / À mettre à jour / Auto / Manuel / Inactifs.
- [x] Historique compact lorsqu aucun événement n est présent.
- [x] Conserver toutes les données détaillées sans donner le même poids visuel aux états normaux et aux anomalies.

## Maintenant
- [ ] Valider la fiche sur 1366 / 1440 / 1920 px avec un site sain, un site No-index et un site avec plusieurs mises à jour.
- [ ] Confirmer que les onglets restent rapides avec un WordPress comportant 40+ extensions.

## Prochaines étapes
- [ ] Ajouter une action de rafraîchissement ciblé du diagnostic depuis la fiche sans recharger le Centre d opérations.
- [ ] Ajouter une vue avant/après lorsqu une intervention Tech modifie SEO, plugin ou contenu.

# Tech AWM 1.7.15 — fiche opérationnelle complète et Mode moniteur

## Livré
- [x] Mode moniteur en fenêtre dédiée pour affichage/cast.
- [x] Numéro, nom et barre Top sites dans la teinte exacte du site.
- [x] URL cartographique cliquable vers le site réel.
- [x] Diagnostic Index/No-index avec canonical, robots.txt, sitemap, HTTP final, URL finale et directives.
- [x] Inventaire complet des extensions WordPress dans la fiche Tech avec état et politique de mise à jour.

## Maintenant
- [ ] Valider sur un principal, un sous-domaine et un sous-dossier que URL/canonical/robots/sitemap correspondent bien à chaque installation.
- [ ] Caster la fenêtre Mode moniteur sur un écran externe et confirmer plusieurs cycles de polling.

## 1.7.14 — flotte WordPress, indexation et identité multi-sites
- [x] Afficher toutes les extensions WordPress par site, avec version, état actif et mise à jour disponible.
- [x] Choix `Manuel / Automatique` par site et extension, sans politique globale implicite.
- [x] Action `Mettre à jour maintenant` pour une extension tierce précise via Hub Client.
- [x] Garder les modules AWM exclusivement sur le canal signé Core.
- [x] Afficher `Indexable / No-index / À vérifier` dans la fiche et la liste des sites, avec cause du diagnostic.
- [x] Une famille de couleur par client sur la carte; teintes distinctes pour principal et secondaires.
- [x] Afficher l URL complète exacte et `Principal / Secondaire` dans légende, tooltip et popup.
- [ ] Maintenant : valider un client avec domaine principal + sous-domaine + sous-dossier et confirmer visuellement les teintes et URL complètes.
- [ ] Maintenant : activer l automatique sur une extension de site pilote et confirmer sauvegarde, mise à jour, inventaire rafraîchi et journal.
- [ ] Prochaines étapes : vue de conformité flotte (à jour / en retard / filesystem bloqué / dernière erreur) et fenêtres de maintenance.

## 1.7.13 — densité opérationnelle du Brief AWM
- [x] Résumé Brief + SLA regroupé sur une ligne en haut du bloc à largeur bureau.
- [x] Cartes de priorités amincies sans retirer les informations opérationnelles.
- [x] Suppression de l espace vertical inutile avant les priorités afin de remonter carte et activité temps réel.
- [x] Responsive conservé pour écrans intermédiaires et mobiles.
- [ ] Maintenant : valider visuellement à 1366 / 1440 / 1920 px et confirmer que la carte remonte suffisamment dans le premier écran.
- [ ] Prochaines étapes : ajouter les filtres Client / Site directement au Centre d opérations pour les gros portefeuilles.

## 1.7.12 — stabilité du Centre d’opérations
- [x] Corriger l’arrêt JavaScript du cockpit causé par l’initialisation SLA avant le helper `num()`.
- [x] Restaurer la carte Leaflet et la courbe de visites sans modifier les données GeoIP ni le polling.
- [x] Ajouter un smoke test runtime du dashboard à la validation de release pour détecter les erreurs d’initialisation que `node --check` ne voit pas.

# Tech AWM 1.7.11 — objectifs SLA configurables

## Livré
- Suspension/reprise automatique de surveillance selon le statut CRM.
- Fermeture traçable des incidents à la désactivation, sans perte d'historique.
- Re-sondage prioritaire des anomalies et MTTD réel via `first_signal_at`.
- Objectifs SLA globaux MTTD / prise en charge / MTTR sans valeur contractuelle inventée.
- Surcharges SLA par client et par `site_id`, avec héritage `site → client → global`.
- Fenêtres SLA 7 / 30 / 90 jours dans le Centre d opérations.
- Conformité calculée uniquement sur les échantillons qui possèdent une cible explicite.
- État SLA par site `Respecté / À risque / Dépassé / Échantillons insuffisants / Objectif non défini`.
- Courriels urgents aux techniciens configurés pour les incidents erreur/critique.
- Escalade courriel optionnelle et unique lorsqu un incident erreur/critique reste sans prise en charge au-delà du délai configuré.

## Maintenant
- Valider les objectifs SLA sur des incidents réels et comparer 7 / 30 / 90 jours.
- Valider l escalade sur un incident test non pris en charge, puis confirmer qu une prise en charge avant le délai annule bien l envoi.
- Déterminer quels services/contrats CRM doivent porter une cible SLA explicite avant d activer cet héritage.

## Prochaines améliorations
- Calendriers d astreinte et règles de routage des escalades selon horaire/équipe; l escalade simple par délai est maintenant livrée.
- Raccord optionnel des objectifs SLA aux services/contrats CRM, sans ambiguïté quand plusieurs services coexistent.
- Tendances mensuelles et historique des périodes de suspension opérationnelle pour Health.

## 1.7.9 — filtres opérationnels et SLA Alliance v1

- [x] Filtres Incidents : `Tous / Nouveau / Pris en charge`.
- [x] Filtres responsabilité : `Tous / À moi / Non assigné`.
- [x] Filtres criticité : `Toutes / Critique / Erreur / Surveillance`.
- [x] Filtres Priorités par criticité et type de signal `Incident / 404 / Mise à jour / Surveillance`.
- [x] SLA compact 30 jours intégré au Brief AWM : incidents observés, prise en charge moyenne, MTTR et taux de prise en charge.
- [x] Aucun MTTD fictif : l interface indique que cet indicateur nécessite l horodatage du premier signal avant confirmation.
- [x] Aucune migration DB; calcul à partir de la DB Tech 1.2.0 existante.
- [ ] Maintenant : valider les filtres avec plusieurs techniciens Alliance et vérifier que `À moi` suit correctement l utilisateur WordPress connecté.
- [ ] Maintenant : valider les mesures SLA sur des incidents réels fermés et pris en charge.
- [ ] Prochaines étapes : instrumenter `first_signal_at` pour produire un MTTD observé fiable, puis consolider SLA par site/client.
- [ ] Prochaines étapes : ajouter les filtres client/site sur les gros portefeuilles sans alourdir le cockpit.
- [ ] Prochaines étapes : re-sondage prioritaire après un premier échec afin de réduire le délai de confirmation.

## 1.7.8 — workflow des incidents

- [x] États humains `Nouveau / Pris en charge / Résolu` dans le Centre d opérations.
- [x] Responsable Alliance et horodatage de prise en charge.
- [x] Notes internes par incident.
- [x] Historique append-only des actions humaines et résolutions automatiques.
- [x] Durée ouverte, temps avant prise en charge et durée totale de résolution.
- [x] La résolution manuelle ne neutralise pas un signal encore actif : le moteur recrée un incident si l anomalie persiste.
- [x] Timeline universelle enrichie avec prise en charge et notes.
- [ ] Maintenant : valider le workflow sur plusieurs incidents réels avec deux utilisateurs Alliance différents.
- [ ] Prochaines étapes : filtres `Nouveau / Pris en charge / Responsable / Criticité` directement dans la vue Priorités.
- [ ] Prochaines étapes : SLA Alliance consolidé (MTTD, délai de prise en charge, MTTR) par client/site et global.

## 1.7.7 — shell Tech compact

- [x] Supprimer le second bandeau de contexte Tech.
- [x] Afficher `Centre technique Alliance · Tech AWM v1.7.7` directement dans l en-tête principal.
- [x] Afficher `Session et actions réservées à Alliance` dans le même en-tête.
- [ ] Maintenant : valider la densité sur 1366 / 1440 / 1920 px et confirmer que les priorités remontent encore dans le premier écran.

## 1.7.6 — densité du Centre d’opérations

- [x] En-tête et contrôles de supervision compactés.
- [x] Six cartes opérationnelles concentrées sur une ligne lorsque la largeur le permet.
- [x] Brief AWM compact avec Top 3 situations conservé.
- [x] Carte et activité temps réel remontées dans le premier écran sans supprimer d’information.
- [x] Responsive 6 / 3 / 2 / 1 colonnes.
- [ ] Maintenant : valider sur écran bureau 1366/1440/1920 px que le cockpit reste lisible à distance et que les six cartes tiennent sans troncature gênante.
- [ ] Prochaines étapes : mode densité automatique selon hauteur disponible et mode TV encore plus compact.
- [ ] Futur : préférences de densité par rôle/utilisateur (Compact / Normal / Présentation).

## 1.7.5 — Timeline universelle v1

- [x] Timeline globale des 24 dernières heures dans le Centre d’opérations.
- [x] Sources réelles v1 : incidents, sondes anormales, actions Tech, formulaires Stats AWM et mises à jour inventoriées.
- [x] Filtres rapides par source et rafraîchissement silencieux.
- [x] Chronologie récente par site dans le popup Tech.
- [x] Conservation stricte de `client_id + site_id`; aucun mélange inter-client.
- [x] Aucun diagnostic causal inventé : la timeline ordonne les faits seulement.
- [ ] Maintenant : valider la lisibilité et le volume d’événements sur le parc réel Alliance pendant une journée complète.
- [x] Livré en 1.7.8 : prise en charge des incidents avec responsable et états `Nouveau / Pris en charge / Résolu`.
- [ ] Prochaines étapes : enrichir la timeline avec Studio, CRM, CallTracker, SERP/Screpy, sauvegardes et déploiements Core.
- [ ] Futur : exploiter cette chronologie dans Health pour proposer une cause probable avec niveau de confiance, sans confondre corrélation et causalité.

## 1.7.4 — Brief AWM et corrélation opérationnelle

- [x] **Corrélation d’incidents v1** : un site remonte comme une seule situation prioritaire même si plusieurs signaux actifs coexistent.
- [x] Les signaux bruts restent visibles dans leurs vues dédiées; le regroupement n’invente pas de cause.
- [x] Tri des situations par sévérité, nombre de signaux et activité réelle du site.
- [x] **Brief AWM** : résumé opérationnel du moment et Top 3 des situations à traiter, cliquables vers la fiche Tech.
- [x] Rafraîchissement silencieux du brief avec le même polling que le cockpit.
- [ ] Maintenant : valider sur le parc réel que les regroupements correspondent bien aux situations réellement vécues par les techniciens.
- [x] Timeline universelle v1 livrée en 1.7.5; l’enrichissement cross-module reste en prochaine étape.
- [x] Livré en 1.7.8 : accusé de prise en charge, responsable et statuts `Nouveau / Pris en charge / Résolu`.

## Futur — vision Centre d’opérations AWM

- [ ] **Score Impact × Urgence × Confiance** pour classer les priorités sans masquer les signaux bruts.
- [ ] **Timeline universelle cross-module** : enrichir la v1 avec Studio, CRM, CallTracker, SEO/SERP, sauvegardes, déploiements Core et campagnes sur une seule ligne du temps.
- [ ] **Centre de mises à jour intelligentes** : classer `Critique / Sécurité / Important / Normal`, snapshot avant mise à jour et vérification automatique après déploiement.
- [ ] **Réparation semi-automatique** pour les cas sûrs : purge cache, relance cron, rollback de mise à jour, restauration ciblée ou désactivation temporaire d’un composant fautif, toujours journalisée et réversible.
- [ ] **SLA Alliance** : MTTD, temps de prise en charge, MTTR, incidents récurrents, sites les plus problématiques et pourcentage réglé avant signalement client.
- [ ] **AWM Live Intervention** : vue client temporaire du site, curseur du tech, changements appliqués et avant/après, sans exposer Tech AWM, Elementor, wp-admin ou les secrets.
- [ ] **Écran TV client intelligent** : santé, activité, leads, appels, SEO, objectifs et indication discrète lorsqu’Alliance intervient.
- [ ] **Health prescriptif** : transformer les constats Stats/Tech en priorités explicables reliées directement aux modules d’action.
- [ ] **Attribution complète jusqu’au revenu** : mot-clé/canal → visite → formulaire/appel → lead CRM → soumission → vente → revenu.
- [ ] **Carte portefeuille à couches** : Visiteurs, Clients, Incidents, Formulaires, Revenus et Opportunités avec filtres et comparaison de périodes.
- [ ] **Morning Brief avancé** : résumé quotidien Direction/Technique avec changements nocturnes, incidents, risques, opportunités et prochaines actions.

## 1.7.3 — cockpit orienté action

- [x] Priorités et incidents remontés en haut du Centre d’opérations.
- [x] Cartes cliquables avec popup : priorités, incidents, erreurs 404, mises à jour importantes, formulaires et sites à surveiller.
- [x] Liste des sites visités en temps réel à côté de la carte.
- [x] Top des sites les plus visités aujourd’hui, classé par pages vues.
- [x] Accès à la fiche Tech depuis les lignes de Top/activité sans exposer d’identité visiteur.
- [ ] Prochaines étapes : télémétrie 404 par URL/page côté site pour distinguer une homepage 404 d’un ensemble de liens cassés.
- [ ] Prochaines étapes : filtres de priorité par criticité, client, type d’incident et responsable.
- [ ] Futur : score Impact × Urgence × Confiance pour classer automatiquement les priorités.

## 1.7.2 — cartographie temporelle du parc

- [x] À l'instant / 1 minute / 1 heure / 1 journée / 1 mois / 3 mois / 1 an.
- [x] Courbe de visites transparente fondue dans la carte globale.
- [x] Conservation du zoom/cadrage pendant les refresh silencieux.
- [ ] Futur : cliquer une portion de courbe pour filtrer les points de la carte sur le même intervalle.
- [ ] Futur : heatmap globale et comparaison période courante/précédente.

# Tech AWM 1.7.1 — roadmap Centre d’opérations, incidents et interventions


## Livré — 1.7.1
- [x] **Clients/sites identifiables sur la carte globale** à partir des points GeoIP actifs de Stats AWM.
- [x] Même rendu visuel que Stats AWM : point lumineux, halo et popup sombre détaillé.
- [x] Conservation de `client_id + site_id` par point de présence afin d’afficher le bon client et le bon site.
- [x] Regroupement multi-clients/multi-sites lorsqu’une même localité est partagée, sans masquer les marqueurs superposés.
- [x] Statut HTTP et nombre de visiteurs actifs visibles dans le popup de carte.
- [x] Carte persistante : aucun recentrage automatique à chaque polling de 30 secondes.
- [x] Aucune duplication du moteur GeoIP; Stats demeure la source de vérité.

## Livré — 1.7.0
- [x] **Centre d’opérations AWM** comme vue principale Tech : tous les clients et sites du registre canonique dans un seul cockpit.
- [x] KPI globaux : sites surveillés, en ligne, erreurs, lents, visiteurs actifs, pages vues, formulaires et temps de réponse moyen.
- [x] Sonde HTTP rotative sécurisée : 12 sites / 2 minutes, timeout 4 s, SSL vérifié, historique 30 jours.
- [x] Registre d’incidents persistant avec ouverture après confirmation, sévérité, première/dernière détection et résolution automatique.
- [x] Incidents v1 : indisponibilité/HTTP, lenteur confirmée, Connector sans contact depuis plus de 2 h et alertes de sécurité Tech.
- [x] Carte globale temps réel alimentée uniquement par les coordonnées GeoIP disponibles dans Stats AWM.
- [x] Trafic horaire global, visiteurs actifs et formulaires réels issus de Stats AWM sans duplication du moteur de collecte.
- [x] État opérationnel global `Normal / À surveiller / Incident / Critique`.
- [x] Tri dynamique des sites en anomalie, incidents ouverts et derniers incidents résolus.
- [x] Actualisation silencieuse 30 s sans flicker et carte Leaflet persistante.
- [x] Mode TV de supervision, recherche globale et accès aux détails Tech existants.
- [x] Isolation `client_id + site_id`; aucune donnée d’un autre client n’est exposée dans une action site-scoped.

## Maintenant
- [ ] Valider sur le parc réel Alliance le coût du lot de 12 sondes, les temps de réponse et les éventuels faux positifs HTTP.
- [ ] Confirmer que le mode TV reste stable plusieurs heures avec les rafraîchissements silencieux et une carte active.
- [ ] Vérifier la cohérence des visiteurs actifs entre Stats AWM et la vue globale sur plusieurs sites simultanément.
- [ ] Mesurer le délai réel de détection sur un site pilote, puis ajuster la cadence selon la charge du serveur central.

## Prochaines étapes
- [ ] **File de re-sondage prioritaire** : lorsqu’un premier échec est détecté, recontrôler rapidement ce site sans attendre un tour complet du parc.
- [ ] Déploiement distant réellement `site_id`-scoped pour installer ou mettre à jour le runtime sur un site secondaire précis sans réutiliser le site principal.
- [ ] Conversation Tech contextualisée par page/site : diagnostic, propositions d’actions sûres, application explicite et rollback.
- [ ] Sonde SSL dédiée : expiration, chaîne, nom de domaine et nombre de jours restants.
- [x] Livré en 1.7.8 : accusé de prise en charge d’un incident, responsable, notes et statut `Nouveau / Pris en charge / Résolu`.
- [ ] Chronologie d’incident : sondes, changement détecté, actions Tech, rollback et retour à la normale.
- [ ] Détection d’anomalies Stats : chute inhabituelle du trafic, des formulaires ou des conversions par rapport à l’historique propre du site.
- [ ] Santé des Connectors : dernière présence, version, transport, erreurs de synchronisation et dérive de runtime.
- [ ] Notifications configurables pour les incidents critiques sans créer de bruit sur les variations brèves.
- [ ] Vue historique 24 h / 7 j du temps de réponse et de la disponibilité par site.
- [ ] Mesures opérationnelles Alliance : MTTD, temps de prise en charge et MTTR.

## Futur — AWM Live Intervention
- [ ] **AWM Live Intervention — vue client d’intervention en direct** : depuis Hub Client, le client voit uniquement son propre site pendant une intervention Alliance active.
- [ ] Afficher le curseur du technicien avec son libellé AWM, le scroll et l’élément sélectionné, sans partager l’écran complet du technicien.
- [ ] Afficher les modifications lorsqu’elles sont appliquées, avec une petite chronologie `titre modifié / image remplacée / espacement ajusté / rollback`.
- [ ] Conserver Tech AWM totalement invisible : aucun wp-admin, panneau Elementor, fenêtre Tech, log, prompt IA, secret ou donnée d’un autre client.
- [ ] Session temporaire liée à `client_id + site_id + instance_uuid`, expiration automatique et fermeture immédiate quand le technicien termine.
- [ ] Mode **Observation** par défaut; futur mode **Collaboration** où le client peut pointer un élément et envoyer un commentaire contextualisé.
- [ ] Comparateur Avant / Après pour les changements importants, en continuité avec le contrat existant Aperçu → Appliquer → Rollback.
- [ ] Lier une session Live Intervention à l’incident d’origine : `incident → prise en charge → intervention visible → résolution → mesure Stats/Health`.

## Futur — Centre d’opérations avancé
- [ ] Worker de sondes externe/asynchrone pour réduire le temps de balayage de grands parcs sans surcharger WP-Cron.
- [ ] Surveillance erreurs PHP/WordPress, WP-Cron bloqué, espace disque, sauvegardes et changements critiques de configuration.
- [ ] Corrélation avec Studio : mise à jour, publication ou modification importante juste avant un incident.
- [ ] Corrélation avec CallTracker, CRM et formulaires afin de détecter une rupture de génération de leads même si le site répond HTTP 200.
- [ ] Health AWM calcule une cause probable et une priorité selon impact, urgence, effort et confiance.
- [ ] Actions rapides depuis l’incident : analyser avec Assistant, ouvrir Soutien, lancer Tech, voir Stats, voir logs et marquer résolu.
- [ ] Vue portefeuille `Urgent / À surveiller / Opportunité / Stable` pour le Morning Brief Alliance.
- [ ] Historique de fiabilité par hébergeur, technologie et site, sans mélanger les données client.

## Règle d’architecture
**Stats mesure → Tech surveille → Health diagnostique → Hub priorise → Studio / Soutien / CRM / CallTracker / Assistant agissent → Stats / Health mesure le résultat.**

Tech AWM reste un agent Alliance invisible dans Hub Client hors d’une surface temporaire Live Intervention explicitement ouverte pour le client. Cette surface ne révèle jamais l’interface Tech elle-même.