← Roadmap publique
README
Tech AWM V1.10.18Snapshot sécurisé de la version effectivement publiée. Les lignes potentiellement sensibles sont masquées automatiquement.## 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.