Contexte développement

# Contexte développement — LeadTracker AWM 1.11.76


---

## CHANGELOG.md

## 2026-10-20 - LeadTracker AWM 1.11.76 - Destinations CRM externes facultatives
- Le tableau de câblage n affiche plus **Capturia · Google — Destination à configurer** sur toutes les campagnes.
- Capturia apparaît uniquement lorsqu il est réellement actif en lecture et/ou en transfert sortant pour la campagne.
- **CRM Client AWM** n est plus affiché en grisé lorsqu il ne s applique pas au client.
- Le KPI devient **CRM externes** afin de ne pas figer l architecture sur Capturia.
- LeadTracker AWM demeure toujours la destination opérationnelle de base; aucun changement au moteur Capturia immédiat validé terrain.

## 2026-10-20 - LeadTracker AWM 1.11.75 - Capturia Identity Mapping v2
- Confirmation terrain recue : un nouveau lead VMV entre maintenant immediatement dans Capturia; le flux central temps reel reste inchange.
- Corrige le mapping ou Capturia pouvait afficher le courriel comme `first_name` lorsque le formulaire ne fournissait pas un prenom reconnu.
- Un nom candidat est maintenant refuse s il ressemble a un courriel, telephone ou URL.
- Nouveaux alias : `Nom du lead`, `Nom du prospect`, `Nom du contact`, `lead name`, `contact name`, `client name`, plus Prenom/Nom de famille FR/EN.
- Un nom complet est decoupe proprement en prenom/nom. Si un seul nom humain est disponible, il devient l identite visible plutot que le courriel.
- Aucun contact historique Capturia n est rejoue ou modifie automatiquement; la correction s applique aux prochains leads.

## 2026-10-19 - LeadTracker AWM 1.11.74 - paquet runtime allégé et historique hors plugin

- Le plugin livré ne conserve plus les dizaines de fichiers RELEASE-NOTES/VALIDATION des anciennes versions.
- Le paquet runtime garde uniquement le code courant, `README.md`, `CHANGELOG.md`, `ROADMAP.md`, les notes/validation de 1.11.74 et `data/history` requis par les outils de migration/rapprochement.
- Les documents historiques sont archivés hors du plugin installé; aucune donnée de migration n'est supprimée.
- Aucun changement métier par rapport à 1.11.73 : Leads = Appels + Formulaires, fiche complète au clic, CPL, Google Ads, Capturia et routage restent inchangés.
- Règle permanente : une nouvelle version ne doit jamais réembarquer les notes/validations unitaires de toutes les versions précédentes.

## 2026-10-19 - LeadTracker AWM 1.11.73 - correctif packaging securise

- Aucun changement fonctionnel par rapport a 1.11.72 : la vue Leads unifiee appels + formulaires et la fiche detaillee au clic sont conservees.
- Le paquet 1.11.72 contenait par erreur deux copies byte-for-byte identiques du module (`calltracker_new/` et `awm-calltracker/`), ce qui portait la taille extraite a environ 381 Mo et declenchait la limite Core de 256 Mo par module.
- Le paquet 1.11.73 ne contient qu une seule racine livrable `awm-calltracker/`; les arbres de travail sont exclus.
- La limite Core n est pas relevee ni contournee : le packaging est corrige a la source.

## 2026-10-19 - LeadTracker AWM 1.11.72 - leads unifies appels + formulaires et fiche detaillee

- La section « Leads de la campagne » additionne maintenant les appels entrants et les formulaires, selon la meme definition que le CPL : appels entrants + formulaires.
- Les compteurs affichent Leads totaux, Appels, Formulaires, puis le detail des moteurs de formulaires.
- Les 20 derniers leads sont fusionnes dans une seule chronologie, avec badge Appel/Formulaire et heure Toronto.
- Un clic sur n importe quel lead ouvre sa fiche detaillee sans quitter la campagne.
- Formulaire : nom, courriel, telephone, formulaire, source, page, statut, message, sujet, reponses completes du payload et references utiles; secrets/token/captcha/API restent filtres.
- Appel : appelant, numero suivi, statut, duree, localisation, Call SID, Child SID, enregistrement protege quand disponible et etapes de routage.
- Les appels ne sont jamais presentes comme des preuves Capturia; Capturia reste applicable aux formulaires VMV-NAT seulement.

## 2026-10-19 - LeadTracker AWM 1.11.71 - liaison Google Ads persistante et historique CPL automatique

- Une association Google Ads devient une configuration persistante : MCC, compte client, mode compte/campagnes et sélection de campagnes sont mémorisés avec une empreinte stable et un historique de liaison.
- Toute modification de cette association déclenche automatiquement un worker de récupération de tout l historique Google Ads disponible, du premier mois réellement observé jusqu au mois courant, sans limiter le recalcul au mois courant/précédent.
- Chaque mois est réconcilié avec le barème AWM officiel 50/40/30/20/15; le rabais continue de s appliquer sur les frais de gestion, jamais sur l investissement.
- Les lignes CPL plus anciennes que la fenêtre vérifiable Google Ads ne sont jamais supprimées ni écrasées.
- Chaque mois conserve désormais des instantanés de résultat Google Ads/CPL : investissement, frais, rabais, coûts annexes, appels, formulaires, leads, coût total et CPL calculé. Le premier résultat reste conservé et les vérifications ultérieures sont auditées.
- Le worker est idempotent par empreinte de configuration et conserve son état (en attente, en cours, complet, partiel ou erreur) pour diagnostic.
- Hub AWM 4.5.90 complète ce contrat en empêchant un enregistrement partiel de vider silencieusement un compte Google Ads déjà associé et en affichant l état de l historique directement dans la campagne.

## 2026-10-18 - LeadTracker AWM 1.11.70 - campagne active = synchronisation automatique

- Nouvelle règle opérationnelle : une campagne publiée dont le statut LeadTracker est `active` doit maintenir automatiquement ses entrées configurées sans clic sur « Synchroniser ».
- Numéro Twilio : à l’activation ou après une modification de campagne, LeadTracker applique le routage entrant puis relit Twilio pour vérifier que le VoiceUrl AWM est réellement actif. Les erreurs restent visibles dans `_callink_twilio_sync_error`; aucune réussite n’est inventée.
- Formulaires : pour toute campagne active ayant des associations/form capture configurées, LeadTracker rafraîchit les inventaires Hub Client, rapproche les formulaires déjà reçus et réapplique les mappings enregistrés. Aucun formulaire non rattaché n’est deviné automatiquement, sauf la règle spéciale VMV-NAT `capturia_auto_all_forms` déjà existante.
- Un worker de convergence traite les changements immédiatement en arrière-plan et recontrôle ensuite les campagnes actives par petits lots. Le numéro est revalidé périodiquement et les formulaires sont rafraîchis sans dépendre d’un opérateur.
- Les changements de statut, numéro, destination, client, mappings ou activation de capture déclenchent automatiquement la convergence de la campagne.
- Le bouton manuel « Synchroniser les formulaires » reste disponible uniquement pour forcer un diagnostic/scan immédiat.
- Hub Client 1.14.33 complète ce contrat : mappings actifs actualisés en arrière-plan et lecture fraîche obligatoire juste avant chaque vraie soumission Elementor, Gravity Forms, Contact Form 7 ou hook AWM.

## 2026-10-18 - LeadTracker AWM 1.11.69 - moteur Capturia central temps réel

- Les nouveaux leads VMV-NAT sont maintenant envoyés à Capturia directement par LeadTracker, dans la même requête que `forms/submit`, via le moteur central déjà utilisé pour la reprise des 563 formulaires historiques.
- Le lead exact est mis en file idempotente par `campaign_post_id + form_row_id`; aucun ancien lead n'est rejoué automatiquement.
- Le chemin normal ne dépend plus d'un second appel mutatif depuis Hub Client : Hub Client reçoit `central_owned=1` et n'a pas le droit de créer un deuxième contact.
- Une preuve centrale est écrite avant l'appel API puis enrichie à chaque étape : Contact, Google, Données, contact_id, request-id, HTTP et heure Toronto.
- En cas de 429, seul le lead exact est replanifié. Une réponse réseau/mutative incertaine reste arrêtée sans rejeu aveugle.
- En mode confidentialité CRM Client AWM, LeadTracker crée et tague le contact puis Hub Client 1.14.32 ajoute uniquement les réponses complètes depuis le miroir local chiffré au même contact et met à jour la même preuve.

## 2026-10-16 - LeadTracker AWM 1.11.68 - preuve Capturia renforcée par lead

- La colonne Capturia affiche maintenant, quand disponibles, l'identifiant du contact Capturia, l'identifiant de requête API, le code HTTP et l'heure de livraison en plus de `Contact ✓ · Google ✓ · Données ✓`.
- Le tableau « Preuve des nouveaux formulaires » expose aussi le request ID et HTTP afin de fournir une preuve technique exploitable sans accès au tableau de bord Capturia.
- `delivery_for_form_ids()` transporte maintenant `request_id` jusqu'à la ligne exacte du lead.
- Aucun envoi supplémentaire n'est généré par l'affichage : la preuve provient uniquement du reçu authentifié envoyé par Hub Client après la vraie tentative Capturia.

## 1.11.67 — Campagne déjà ouverte : accès direct leads/export (2026-10-16)
- Dans Câblage des leads, si la campagne sélectionnée est déjà celle de l'URL `lt_campaign`, le bouton principal devient « Voir les leads / Export » et pointe uniquement vers l'ancre locale `#lt-editor-{id}`.
- Évite un rechargement inutile et empêche le loader Hub de croire à une nouvelle navigation pour la même campagne.
- Les autres campagnes conservent « Gérer dans LeadTracker » avec la navigation complète habituelle.
- Aucun changement aux exports CSV 1.11.66, Capturia, formulaires, CPL, Twilio ou historiques.

## 2026-10-16 - LeadTracker AWM 1.11.66 - export funnel complet avec Capturia

- Corrige l export CSV de campagne afin d inclure les leads déjà envoyés ou déjà présents dans Capturia, au lieu de les exclure.
- L export fusionne les soumissions LeadTracker et les archives Capturia de la campagne, en privilégiant la ligne formulaire comme source principale.
- Déduplication conservatrice : lien technique contact/formulaire quand disponible; sinon même courriel ou téléphone normalisé dans une fenêtre maximale de 24 h, en un-à-un.
- Un lead présent uniquement dans Capturia reste dans le CSV avec la provenance `Archive Capturia uniquement`; il n est pas perdu.
- Nouvelles colonnes client : Présent dans Capturia, Statut Capturia, ID contact Capturia et Provenance export.
- Les filtres Du/Au et le choix des formulaires rattachés sont conservés. Un contact Capturia lié à un formulaire décoché ne peut pas être réintroduit par l archive.
- `capturia_unassigned` reste exclu car il n appartient pas encore à la campagne VMV-NAT.
- Export strictement en lecture seule : aucun courriel, aucun appel API Capturia et aucune mutation de lead.

## 2026-10-16 - LeadTracker AWM 1.11.65 - export CSV par campagne

- Nouvelle section **Export CSV des formulaires** directement sous la liste des leads d'une campagne.
- Choix de la période (Du/Au) et des formulaires rattachés, tous présélectionnés par défaut.
- Export client lisible: identité, téléphone, formulaire, page d'origine, message et champs de formulaire, sans secrets techniques ni contacts importés de Capturia.
- CSV UTF-8/Excel FR-CA, protection anti-injection et limite de sécurité de 25 000 lignes.
- Aucun envoi, courriel ou mutation n'est déclenché par l'export.

## 2026-10-16 - LeadTracker AWM 1.11.64 - ordre d'envoi Capturia autoritaire dans forms/submit

- Corrige le cas terrain où LeadTracker recevait immédiatement le formulaire VMV-NAT mais Hub Client n'obtenait aucune preuve Capturia.
- La réponse authentifiée `forms/submit` transporte maintenant une instruction PII-free `capturia_dispatch` calculée sur Alliance pour la campagne exacte qui vient d'être enregistrée.
- Cause racine terrain supplémentaire corrigée : `connector_vmv_credential()` exigeait encore au moins un mapping formulaire individuel alors que VMV-NAT est maintenant en mode `capturia_auto_all_forms`. Cette ancienne garde pouvait accepter le lead dans LeadTracker puis refuser silencieusement la credential Capturia. La route auto-all-forms n exige plus de mapping individuel sur le WordPress principal VMV.
- Hub Client n'a plus besoin de redécouvrir l'intention Capturia via une seconde lecture de `forms/campaigns` avant l'envoi; un cache, une synchronisation de mappings ou une lecture transitoire ne peut donc plus annuler silencieusement la livraison.
- L'instruction ne contient jamais la clé API. Elle indique uniquement demandé/autorisé, campagne, mode tous formulaires et, en cas de blocage, un code/message technique.
- Si la route centrale est invalide, le prochain Hub Client peut enregistrer une preuve `Bloqué` avec la raison exacte au lieu de laisser le lead en `Sans preuve`.
- Corrige aussi le repli des anciennes clés par campagne : si VMV-NAT ne porte pas elle-même le secret mais qu une seule connexion Capturia du même client existe, le Connector réutilise cette source autorisée au lieu de retourner `clé illisible`.

## 2026-10-15 - LeadTracker AWM 1.11.63 - Capturia automatique pour tous les formulaires VMV-NAT

- Le contrat Connector annonce `capturia_auto_all_forms` pour VMV-NAT lorsque la destination Capturia est active.
- Le câblage n exige plus de sélectionner manuellement chaque formulaire VMV-NAT : Hub Client capture automatiquement les formulaires du site principal, tout en respectant une association explicite à une autre campagne.
- Activer Capturia maintient la réception LeadTracker active pour la campagne; désactiver Capturia redevient un choix explicite.
- Les preuves restent rattachées au lead exact et affichées en America/Toronto.

## 2026-10-15 - LeadTracker AWM 1.11.62 - preuve Capturia par lead et heure Toronto

- Corrige l affichage des heures VMV-NAT : les horodatages techniques restent en UTC mais la page Cablage des leads les affiche maintenant via l horloge Core America/Toronto avec HAE/HNE automatique.
- La liste des leads VMV-NAT ajoute une colonne Capturia par formulaire : Confirme, En attente, Bloque, A confirmer ou Aucune preuve technique recue.
- La preuve expose les etapes techniques Contact / Google / Donnees afin de distinguer creation du contact, etiquette et notes sans ouvrir Capturia.
- Le recu technique accepte source, identifiant de formulaire, phase et curseur de notes; il reste strictement sans nom, courriel, telephone ni contenu de formulaire.
- Le connecteur accepte un submitted_at_utc explicite. Une resoumission idempotente recente peut reconciler l heure UTC et completer nom/courriel/telephone manquants sans creer un doublon.
- Le cablage Capturia VMV-NAT accepte maintenant tout formulaire explicitement associe sur le site principal parmi Elementor, Gravity Forms et Contact Form 7; le moteur du formulaire ne peut plus etre un motif de rejet silencieux.
- Aucun historique 563 n est relance par cette version.

## 2026-10-15 - LeadTracker AWM 1.11.61 - vrai contact Elementor et séparation CRM / preuve

- Les nouveaux formulaires Hub Client utilisent le vrai **nom, courriel et téléphone** lorsque ces données existent; `Demande Web` devient le dernier recours uniquement si aucune identité exploitable n est disponible.
- Les libellés Elementor français/anglais courants sont reconnus : nom complet, prénom/nom, courriel/email, téléphone/cellulaire/mobile et variantes proches.
- En mode `local_mirror_v1`, LeadTracker conserve seulement l identité opérationnelle minimale nécessaire à l affichage et à la déduplication; les réponses complètes restent dans le miroir local chiffré et sont envoyées au CRM Capturia pour VMV-NAT.
- La table de preuve Capturia demeure sans PII et continue d afficher uniquement le statut de livraison, les identifiants techniques et les horodatages.
- Les journaux ajoutent seulement des indicateurs booléens `identity_*_present`; aucune valeur nominative n est écrite dans le journal de sécurité.
- La récupération de tous les contacts Capturia manquants de 1.11.60 est conservée sans changement.

## 2026-10-15 - LeadTracker AWM 1.11.60 - Capturia : preuve des nouveaux envois et récupération des archives manquantes

- Ajoute dans **Câblage des leads > VMV-NAT** une preuve technique des nouveaux formulaires envoyés vers Capturia : statut, identifiant de ligne AWM, identifiant contact Capturia et horodatage, sans stocker de nouvelle copie nominative dans la table de preuves.
- Ajoute **Récupérer tous les leads Capturia manquants** : AWM parcourt tous les contacts lisibles par la clé API Core de Vendre Maison Vite, compare les identifiants Capturia et les formulaires déjà connus, puis importe uniquement les contacts absents de l archive courante.
- Les contacts déjà issus des 563 formulaires historiques acceptés ou des nouveaux formulaires AWM sont reliés à leur ligne existante plutôt que dupliqués.
- Une attribution de campagne ambiguë n est jamais forcée : le contact est conservé comme **Capturia - à classer** au niveau du client et reste hors CPL jusqu à qualification.
- Le scan respecte les pauses HTTP 429 et reprend par WP-Cron / AJAX. Aucun scan ni nouvel envoi n est lancé à l installation.
- VMV-NAT reste une campagne SEO pour le CPL; `Google` reste uniquement la destination Capturia.

## 2026-10-15 - LeadTracker AWM 1.11.59 - Capturia : reprise adaptive apres HTTP 429

- La reprise historique VMV-NAT n envoie plus plusieurs formulaires simultanement : un seul formulaire est traite par passage, avec espacement des requetes d ecriture.
- Capturia HTTP 429 n est plus traite comme une erreur fatale : LeadTracker lit `Retry-After` / `RateLimit-Reset` quand disponible, applique une pause globale, puis reprend automatiquement.
- Le navigateur et WP-Cron partagent un verrou de traitement afin d eviter deux workers Capturia concurrents sur la meme campagne.
- Les lignes deja acceptees restent acquises; les lignes en attente/retry conservent leurs cles d idempotence. Aucun formulaire n est reinitialise par la mise a jour.
- Pendant un backfill actif, le bouton de verification Capturia ne lance plus de nouvelles requetes inutiles : il affiche l etat du transfert et la pause eventuelle.
- Aucun envoi Capturia n est declenche a l installation. VMV-NAT reste SEO pour le CPL et Capturia reste reserve a Vendre Maison Vite.

## 2026-10-15 - LeadTracker AWM 1.11.58 - Cablage Capturia lit correctement la cle Core

- Corrige le faux message « La cle API Capturia est absente ou illisible » dans **Cablage des leads > VMV-NAT** alors que la meme cle est validee dans Core AWM et dans la fiche campagne.
- Cause : une connexion Capturia geree par Core n appartient volontairement a aucune campagne (`campaign_id=0`). Le bouton de verification transmettait ce `0` au moteur Capturia, qui ne pouvait alors pas retrouver le client Vendre Maison Vite ni la cle Core.
- Correction : la verification utilise VMV-NAT comme contexte de campagne lorsque la credential vient de Core; le chemin historique conserve son identifiant de campagne d origine.
- L interface indique maintenant explicitement « Cle Capturia geree dans Core AWM pour Vendre Maison Vite » au lieu de « campagne #0 ».
- Aucun changement de cle, aucun envoi Capturia et aucun backfill ne sont executes a l installation. La reprise historique 564 formulaires de 1.11.57 reste manuelle et idempotente.


## 2026-10-15 - LeadTracker AWM 1.11.57 - VMV-NAT : reprise des 564 formulaires vers Capturia Google

- Ajoute une reprise historique manuelle et idempotente pour **VMV-NAT uniquement** : les formulaires deja rattaches a la campagne sont figes dans un instantane puis envoyes par lots vers Capturia avec l etiquette normale **Google**.
- Le traitement conserve un etat technique par formulaire (sans PII), reprend apres interruption et stoppe les resultats reseau incertains au lieu de rejouer aveuglement une creation.
- Les formulaires dont la source est deja `capturia` ne sont jamais renvoyes. Un formulaire sans courriel ni telephone reste bloque et visible dans le bilan.
- Avant le premier envoi, LeadTracker exige une confirmation explicite que l import historique ne declenchera pas une sequence SMS/courriel indesirable dans Capturia.
- Le statut commercial CRM **Actif/Inactif** est desormais independant des campagnes et des leads : `Inactif` ne bloque plus l activation de campagne, Capturia ou la collecte. Un dossier archive/supprime ou un rattachement non canonique reste bloque.
- La campagne reste classee **SEO** pour le CPL. La destination Capturia `Google` ne transforme pas VMV-NAT en campagne Google Ads.
- Aucun envoi n est lance a l installation : l operateur doit ouvrir Cablage des leads > VMV-NAT et confirmer la reprise.

## 2026-10-15 - LeadTracker AWM 1.11.56 - Capturia gere dans Core

- LeadTracker ne propose plus de champ pour enregistrer/remplacer la cle Capturia. Le bouton ouvre `Core AWM > Connexions > Coffre et cles`.
- Pour les campagnes du client CRM **Vendre Maison Vite**, la cle centralisee Core est lue en priorite en memoire serveur.
- Les anciennes cles chiffrees par campagne restent lisibles temporairement comme repli, sans nouvelle ecriture dans LeadTracker.
- Un remplacement de cle dans Core invalide uniquement les caches de capacites/compte/sources; aucun lead historique ni mapping CPL n est purge.
- La planification Capturia reconnait aussi une campagne active utilisant la cle Core meme si aucun ancien meta de cle n existe.
- Capturia n est pas active pour les autres clients.

## 2026-10-14 - 1.11.55 / Suite AWM 4.5.404 - CRM Clients

Nouvelle vue CRM Clients - resultats, en lecture directe sans cache nominatif. Les lecteurs et collecteurs historiques restent disponibles.

Candidate de migration additive : tests locaux, essai WordPress/MySQL et sites clients requis.
Aucun transfert a l'installation. Ne supprime ni sources historiques, ni audio Twilio.
Un seul lancement global depuis CRM AWM > CRM Clients - campagnes et leads.
Prealables : trousseau Core enrole et sauvegarde separement; Hub Client 1.14.22 sur sources et destination; autorisations techniques.
Le statut commercial et le statut des campagnes ne sont pas modifies. Capturia n'est jamais exige ni active pour les autres clients.

---

## LeadTracker AWM 1.11.54 — Statut client CRM canonique à l'activation de campagne (13 octobre 2026)
- La garde d'activation respecte le statut CRM du véritable dossier client `callink_client`; un CRM Actif n'est plus bloqué par `_callink_status=disabled` ou `_callink_manual_inactive=1` hérités.
- Client absent, supprimé, avec mauvais rôle ou non canonique : activation refusée avec identifiant et message de rattachement; CRM Inactif/Archivé et campagnes brouillon/archivées restent refusés.
- Aucun rapprochement ni mutation automatique du `client_id` historique; si le lien de campagne pointe vers un autre dossier, la réconciliation doit être vérifiée séparément.
- Aucun recalcul CPL, aucune réattribution de lead, et aucun envoi Capturia dans cette version.

## 1.11.53 — Correctifs UI statut et périmètre Capturia — 2026-10-13
- Bouton de statut réel dans Modifier et Câblage, action AJAX confirmée, retour visuel instantané, réponse d'erreur non trompeuse.
- Liste campagnes : confirmation avant clic, état attendu/choisi explicites.
- Capturia masqué sur les campagnes non configurées; détails limités à l'usage pertinent.
- Contrôles WordPress/Core AWM/CRM et journal opérateur + timestamp + avant/après, mise à jour conditionnelle en base.
- Pas de migration ni de modification silencieuse des campagnes, formulaires, Capturia, numéros ou CPL.
- Test unitaire local terminé, déploiement terrain et publication roadmap publique à confirmer.

## 1.11.52 — Trois statuts distincts dans les campagnes — 2026-10-13
- Trois indicateurs indépendants dans l’éditeur de campagne et dans « Câblage des leads » : session WordPress Alliance, état métier `_callink_status`, Capturia lecture/écriture/validation.
- « Connexion active » n’est plus affiché comme preuve que la campagne reçoit des leads. Les campagnes en pause restent en pause, aucun lead ni CPL modifié.
- Les permissions Capturia absentes sont présentées comme « inconnues » et non comme lecture seule certaine. Une vérification en lecture ne valide jamais un envoi réel; messages d’avertissement cohérents.
- Libellés et pastilles accessibles, responsives et adaptés aux modes clair/sombre. Validation terrain et publication effective de la roadmap publique en attente.

## 1.11.51 — VMV-NAT (SEO) vers Capturia Google avec connexion existante — 2026-10-12
- Gestion directe sur LeadTracker → Câblage des leads → VMV-NAT (#2636) : formulaires, leads, source CPL, historique et rapprochement strictement manuel des leads non attribués.
- Nouveau choix explicite « Activer le routage automatique des nouveaux leads SEO vers Capturia Google » ; obligation de source SEO et formulaire Elementor du site principal, sans activer silencieusement une campagne en pause.
- Réutilise la clé Capturia du même client CRM déjà chiffrée dans Core AWM, sans champ de mot de passe ou nouvelle clé. Résolution refuse les secrets d'autres clients et les comptes ambigus.
- Publie les champs `marketing_source` et `capturia_requested` sur l'API Connector sécurisée pour le site VMV principal ; ne change pas les soumissions ni coûts Google Ads.
- Les envois Capturia sortants sont réalisés par Hub Client sur la base de soumissions locales chiffrées, uniquement après validation scopes d'écriture + étiquette Google. Envois réels non vérifiés sur le tenant.

## 1.11.51 — VMV-NAT : configuration et leads depuis le câblage — 2026-10-12
- Vue de configuration directement dans LeadTracker : formulaire par site, activation capture, statut explicite de campagne, provenance CPL et consultation des leads historiques.
- Bouton de rapprochement **avec consentement explicite** pour les soumissions Elementor déjà présentes dans LeadTracker mais encore sans campagne ; matching strict client/domaine/formulaire, zéro déplacement intercampagne, historique conservé.
- Destination Capturia « Google » visible comme projet de transfert, clé API sauvegardée chiffrée via Core, contrôle manuel en **lecture seule** ; le transfert sortant n'est pas activé avant la validation réelle du contrat API écrit et du tag.
- Garde contre l'activation d'une campagne archivée/non publiée ou d'un client désactivé ; logs Core AWM, actions POST nonce/capability/owner, fuite inter-site évitée.
- VMV-NAT #2636 de Vendre Maison Vite : **aucune modification automatique des données de production**, test terrain à confirmer ; retour du site historique Elementor nécessitera une source indépendante si les leads n'ont jamais atteint LeadTracker.

## 1.11.50 — Gestion par type de source CPL — 2026-10-10
- SEO n applique plus aucun pourcentage de frais de gestion : le coût SEO mensuel entre directement dans le CPL.
- Autre propose explicitement « Frais de gestion : Non / Oui ».
- Si Oui, le stagiaire choisit un pourcentage ou un montant fixe mensuel.
- L harmonisation historique applique coût + règle de gestion choisie sur tous les mois et crée les mois manquants.
- Le barème AWM 50/40/30/20/15 % est désormais réservé aux campagnes Google Ads et ne peut plus écraser SEO/Autre.
- Les calculs dashboard, campagne, client et historique tiennent compte des frais fixes sans les convertir artificiellement en pourcentage.

## 1.11.49 — Sources CPL Google Ads / SEO / Autre — 2026-10-10
- Chaque campagne choisit maintenant explicitement Google Ads, SEO ou Autre comme source de coût.
- SEO/Autre acceptent un montant mensuel fixe et un premier mois, puis harmonisent tout l historique en un clic.
- La mise à jour globale sait traiter automatiquement les sources API et les sources fixes.
- Les coûts annexes existants sont préservés pendant l harmonisation.

## 1.11.48 — Historique Google Ads sans dates de campagne — 2026-10-10
- Corrige l erreur terrain `UNRECOGNIZED_FIELD` sur `campaign.start_date` / `campaign.end_date` : LeadTracker ne dépend plus de ces champs pour trouver le début de l historique.
- Vérifie seulement que les campagnes Google Ads cochées existent et sont accessibles, puis lit directement toute la fenêtre mensuelle Google Ads disponible avec `segments.month`.
- Détermine le premier mois réel à partir des lignes mensuelles retournées par Google Ads et ne crée/corrige aucun mois antérieur à cette première observation.
- Conserve les lignes CPL plus anciennes que la première donnée Google Ads trouvée au lieu de les transformer artificiellement en mois à 0 $.
- Le catalogue global ne considère plus un ancien taux 7 % comme preuve suffisante qu une campagne doit être câblée à Google Ads; les campagnes `GADS`/Google Ads ou déjà reliées restent détectées.
- Ajoute un compteur interne des historiques 7 % non classifiés pour diagnostic, sans les afficher comme erreurs au stagiaire.

## 1.11.47 — Historique Google Ads résilient et CPL lisible — 2026-10-10
- Remplace la récupération historique longue par une lecture interne découpée par année à granularité `segments.month`; une seule action utilisateur continue de récupérer toutes les années et tous les mois disponibles.
- Si Google Ads refuse une tranche annuelle, LeadTracker reprend automatiquement mois par mois afin d isoler le mois fautif sans demander une intervention manuelle.
- Les erreurs Google Ads analysent maintenant les détails `GoogleAdsFailure` afin d afficher le vrai code/message et le chemin du champ, plutôt que le seul message générique `Request contains an invalid argument`.
- Le catalogue global distingue désormais les CPL Google Ads réellement à configurer des autres campagnes qui ne sont simplement pas concernées par Google Ads.
- Les métadonnées de synchronisation exposent le nombre de tranches annuelles, les mois relus en repli et les request-id utiles au diagnostic.

## 1.11.46 — Synchronisation globale Google Ads → tous les CPL — 2026-10-10
- Ajoute une opération globale en un clic qui parcourt toutes les campagnes CPL câblées à Google Ads et récupère, campagne par campagne, toutes les années et tous les mois mensuels encore disponibles.
- Chaque CPL conserve son propre câblage multi-campagnes; les coûts des campagnes Google Ads cochées sont additionnés mois par mois avant réconciliation.
- Après une récupération Google Ads complète sans erreur, applique le barème AWM officiel à toutes les lignes CPL de la base : 50 % / 40 % / 30 % / 20 % / 15 %.
- Le barème global supprime les anciens verrous manuels sur le taux de gestion, mais ne touche jamais au rabais, au réceptionniste, aux autres coûts ni au PPC sécurisé.
- Les investissements entre 0,01 $ et 99,99 $ restent signalés À vérifier puisqu aucun barème AWM n est défini sous 100 $.
- La file globale est exécutée séquentiellement côté interface afin d éviter une requête PHP unique trop longue; une erreur Google Ads n arrête pas les autres campagnes, mais bloque le recalcul global final pour ne pas recalculer un CPL sur une dépense périmée.

## 1.11.45 — Google Ads historique mensuel automatique — 2026-10-09
- Corrige l erreur terrain `Request contains an invalid argument` lors d un audit historique couvrant plusieurs années.
- Les séries historiques utilisent maintenant `segments.month` au lieu de `segments.date`, ce qui évite la limite de granularité quotidienne des longues périodes.
- Un seul audit récupère automatiquement tous les mois disponibles, additionne toutes les campagnes Google Ads cochées et corrige les lignes CPL sans lancer chaque mois manuellement.
- Si le début de campagne dépasse la rétention mensuelle Google Ads, LeadTracker conserve les mois plus anciens sans les écraser et signale la période réellement vérifiable.
- Rabais, réceptionniste, autres coûts, PPC sécurisé et logique de gestion AWM restent inchangés.

## 1.11.44 — Audit historique Google Ads mois par mois — 2026-10-09
- Ajoute un audit autoritaire de l investissement Google Ads depuis le début des campagnes Google Ads cochées jusqu au mois actuel.
- Récupère la série mensuelle Google Ads en une seule lecture agrégée par `segments.month`, y compris pour plusieurs campagnes affectées au même CPL.
- Compare chaque mois avec l historique CPL; remplace automatiquement tout investissement différent et recalcule le barème AWM 50/40/30/20/15 %.
- L audit explicite peut corriger un investissement anciennement marqué manuel/legacy; rabais, réceptionniste, autres coûts et PPC sécurisé restent inchangés.
- Les mois absents sont créés afin d obtenir une chronologie continue depuis le début Google Ads.
- Sous 100 $ (hors zéro), l investissement est corrigé mais le taux de gestion reste à vérifier car aucune règle AWM n est définie.
- Les lignes antérieures à la date de début des campagnes Google Ads actuellement cochées sont conservées et exclues de l audit.

## 1.11.43 — Google Ads multi-campagnes pour un CPL — 2026-10-09
- Le moteur Google Ads accepte maintenant une liste de campagnes pour une même campagne LeadTracker/CPL.
- Ajoute `_callink_google_ads_campaign_ids` avec repli transparent sur l ancien `_callink_google_ads_campaign_id`.
- `fetch_monthly_spend()` interroge toutes les campagnes sélectionnées avec `campaign.id IN (...)` et additionne leurs `metrics.cost_micros`.
- La synchronisation et le backfill historique 7 % utilisent la même sélection multi-campagnes.
- Les métadonnées de provenance CPL conservent à la fois le premier ID legacy et la liste complète des IDs.

## 1.11.42 — moteur de recherche du câblage — 2026-10-08
- Ajoute une recherche instantanée sur campagne, client, domaine, formulaire, numéro, source Capturia, CRM Client AWM et état.
- Recherche multi-termes insensible aux accents et sans rechargement de page.
- Ajoute les filtres Tous / Fonctionnels / À vérifier avec compteurs.
- Ajoute compteur de résultats, état vide, effacement rapide et raccourci clavier `/`.
- Aucun changement aux données, au CPL, à Capturia, à Twilio ni aux identifiants techniques `callink_*`.

## 1.11.41 — LeadTracker AWM, câblage visuel et confidentialité locale — 2026-10-07
- Le nom produit visible passe de CallTracker AWM à **LeadTracker AWM** sans renommer les identifiants techniques `callink_*` ni le dossier `awm-calltracker`.
- Ajoute **Câblage des leads**, une vue visuelle Entrées → Attribution → Destinations par campagne.
- Affiche les formulaires Elementor / Gravity Forms / Contact Form 7, les numéros, Capturia, LeadTracker et CRM Client AWM dans le même parcours.
- Le endpoint formulaire accepte `privacy_mode=local_mirror_v1`: nom, courriel et téléphone bruts ne sont pas conservés au centre dans ce mode.
- Ajoute `phone_hash` à l historique formulaires pour conserver la déduplication CPL sans téléphone en clair.
- La déduplication Capturia sait comparer les empreintes téléphone des leads locaux privés aux leads Capturia.
- Les clients sans CRM Client AWM conservent le transport historique afin d éviter une migration silencieuse de la flotte.

## 1.11.40 — Capturia : clé validée, heures cohérentes et CPL sans doublon — 2026-10-06
- Le panneau Capturia affiche maintenant **Clé validée** dès que `tags:read` et `contacts:read` sont prouvés par des synchronisations réussies, même si le preset `/me` n’a pas encore été analysé.
- Une lecture réussie de `/tags` et `/contacts` mémorise explicitement ces capacités afin que le diagnostic ne reste plus bloqué sur « À analyser » après un import réel.
- La date de **Réconciliation tag**, stockée en UTC pour la cohérence interne, est convertie dans le fuseau WordPress au rendu afin d’être alignée avec les autres heures du panneau.
- Le dénominateur CPL déduplique maintenant Capturia contre les formulaires AWM de la même campagne : même courriel ou téléphone normalisé, dans une fenêtre de 24 h, avec appariement un-à-un.
- Les doublons ne sont jamais supprimés de l’historique; ils sont seulement exclus du décompte CPL Capturia. Le panneau affiche **Doublons AWM exclus** pour rendre la règle visible.
- Les `email_hash` des anciens `legacy_email` Laravel ne sont pas utilisés comme preuve d’identité, car ils peuvent représenter le message et non le prospect; le téléphone reste utilisable lorsqu’il est disponible.
- La Source Capturia, son UUID, l’import historique, le pipeline et le rapprochement CRM #57 → #275 restent inchangés.

## 1.11.39 — Capturia : consolidation du dossier CRM actif — 2026-10-06
- Corrige le cas terrain où la campagne VMV était encore liée au client WP historique #57 alors que CRM AWM affiche le dossier opérationnel Olivier Lepage #275 comme Actif.
- La résolution Capturia ne considère plus `_callink_legacy_user_id` comme preuve suffisante lorsqu'il pointe vers un dossier inactif ou archivé.
- Le client legacy fournit maintenant nom, courriel, entreprise et téléphone comme preuves d'identité; CallTracker recherche le dossier CRM actif correspondant.
- Un dossier CRM actif unique est préféré lorsqu'il correspond fortement à la même identité réelle (courriel, téléphone, ou nom + entreprise). En cas d'ambiguïté entre plusieurs dossiers actifs, le connecteur reste prudent et ne choisit pas arbitrairement.
- Le diagnostic distingue maintenant `Campagne WP`, `legacy`, `Client lié` et `CRM`, et affiche les preuves d'identité utilisées.
- Aucun changement Capturia API : la source sélectionnée et `/v1/contacts?tag=<UUID>` restent inchangés.

## 1.11.38 — résolution canonique du client Capturia — 2026-10-06
- Corrige un second faux « client inactif » : un identifiant legacy/WHMCS stocké dans la campagne pouvait être interprété comme un ID utilisateur WordPress avant la lecture du statut CRM.
- Pour les campagnes historiques, `_callink_legacy_campaign_id` est maintenant résolu via `data/callink-legacy-data.json`, puis vers le client CRM canonique par `_callink_legacy_user_id` ou l’adresse courriel legacy exacte.
- Les campagnes modernes continuent d’utiliser directement leur ID client WordPress canonique.
- Les IDs WHMCS/legacy bruts sont normalisés uniquement lorsqu’un seul client CRM canonique correspond exactement.
- Capturia n’appelle plus `canonical_client_status()` avec un identifiant non canonique.
- Les leads Capturia importés utilisent aussi l’ID CRM canonique résolu.
- Le diagnostic affiche `Campagne #… → CRM #…` et distingue un vrai statut Inactif d’un simple lien client incohérent.
- Aucun changement de schéma et aucune réattribution silencieuse de campagne : la normalisation est utilisée par le connecteur Capturia sans réécrire les autres historiques.

## 1.11.37 — republication forcée du correctif Capturia — 2026-10-06
- Republie sous un numéro strictement supérieur le correctif Capturia livré en 1.11.36 afin d’éviter qu’un ancien build portant déjà `1.11.36` soit considéré à tort comme courant.
- Conserve CRM AWM comme unique autorité du statut client pour **Récupérer les leads**.
- Conserve le menu **Source Capturia**, le UUID interne de la source et l’import ciblé `/contacts?tag=<UUID>`.
- Aucun changement de schéma de données; le but est de garantir le déploiement effectif du bon build sur Alliance.

## 1.11.36 — 2026-10-06
- Corrige le faux blocage **« client inactif »** observé pendant **Récupérer les leads** Capturia.
- Capturia utilise désormais `CallLink_CRM::canonical_client_status()` / `canonical_client_is_active()` comme autorité de cycle de vie, exactement comme les autres fonctions opérationnelles AWM.
- Supprime du garde Capturia l’usage de `AWM_Core_Access::is_approved()` et du vieux `_callink_status=disabled` : l’accès portail/Core n’est pas le statut CRM du client.
- Ajoute un repli compatible sur `_callink_crm_account_status`, `_callink_manual_inactive` et l’état WHMCS legacy uniquement si la classe CRM n’est pas encore chargée.
- Ajoute **Statut client CRM** dans le diagnostic Capturia et précise qu’une suspension réelle vient de CRM AWM.
- Les sources Capturia, UUID, clé chiffrée, import de contacts, pagination, CPL et pipeline restent inchangés.

## 1.11.35 — 2026-10-05
- Remplace la saisie technique du tag Capturia par un vrai menu **Source Capturia** alimenté par `GET /v1/tags`.
- Le menu conserve uniquement les tags de catégorie `source` et les tags de campagne dont `system_key` commence par `campaign:`; les campagnes sont regroupées en premier.
- Ajoute l’action **Synchroniser les sources** : CallTracker recharge la liste depuis Capturia, conserve le UUID en interne et affiche le nom lisible à l’administrateur.
- **Récupérer les leads** utilise ensuite `GET /v1/contacts?tag=<UUID>` et exige une source sélectionnée pour les nouvelles configurations afin d’éviter l’import accidentel de tout le compte.
- Permissions minimales documentées : `tags:read` + `contacts:read`. La clé API reste chiffrée dans Core AWM et n’est jamais réaffichée.
- Une nouvelle clé Capturia purge aussi le cache de sources de l’ancien tenant afin de ne jamais proposer une source d’un autre compte.
- Les anciennes configurations explicitement confirmées « tous les contacts » restent tolérées côté moteur pour compatibilité, mais ne sont plus proposées dans le nouveau parcours.

## 1.11.34 — 2026-10-05
- Corrige la règle métier du backfill 7 % : **7 % signifie valeur par défaut/legacy à remplacer**, pas valeur manuelle à protéger.
- Pour chaque mois à 7 %, CallTracker relit le vrai investissement depuis Google Ads, remplace l'investissement historique, puis applique le barème AWM 50/40/30/20/15 %.
- Les verrous/provenances manuels hérités d'une migration sont ignorés uniquement pour ces lignes à 7 %; réceptionniste, autres frais, rabais et PPC sécurisé sont conservés.
- Les investissements Google Ads sous 100 $ sont laissés intacts et signalés À vérifier, faute de règle de gestion définie sous 100 $.

## 1.11.33 — 2026-10-05
- Corrige le backfill historique : le taux exact de 7 % est désormais le marqueur de correction, sans dépendre de `source=legacy` ou `legacy_imported`.
- Les taux explicitement marqués manuels restent protégés; les investissements manuels continuent de primer sur Google Ads.

## 1.11.32 — 2026-10-05
- Ajoute la provenance par champ CPL, protège les saisies manuelles et corrige les lignes historiques à 7 % avec le coût réel Google Ads et le barème AWM officiel.
- Une différence Google Ads sur un investissement manuel devient une proposition automatique visible, jamais un écrasement silencieux.

## 1.11.31 — CPL complet et automatisé — 2026-10-04
- Ajoute un état de complétude mensuel du CPL : **Complet**, **Complet · 0 lead** ou **À compléter**.
- Le diagnostic regroupe investissement, source/devise, fraîcheur Google Ads, barème de gestion, rabais, réceptionniste, autres coûts, appels entrants, formulaires AWM, Capturia et CPL final.
- Ajoute des paramètres mensuels par campagne pour **rabais**, **réceptionniste** et **autres coûts**, applicables automatiquement aux nouvelles lignes créées par Google Ads.
- Une valeur à `0` peut maintenant être explicitement confirmée; elle n'est plus confondue avec un champ simplement oublié.
- Corrige la provenance : modifier uniquement réceptionniste/autres/rabais ne transforme plus une ligne Google Ads en ligne manuelle tant que l'investissement reste inchangé.
- Un changement manuel de l'investissement devient explicitement `manual_override` et le barème de gestion est recalculé.
- Les synchronisations Google Ads fusionnent leurs métadonnées au lieu d'effacer la confirmation des coûts annexes.
- Ajoute une synchronisation Google Ads complète en arrière-plan pour toutes les campagnes associées, avec progression campagne par campagne et traitement accéléré par petits lots.
- Conserve les périodes courante et précédente comme fenêtres automatiques de coût Google Ads; les mois historiques restent lisibles sans être déclarés périmés.
- Aucun changement au dénominateur CPL : appels entrants + formulaires AWM + leads Capturia explicitement inclus.

## 1.11.30 — correctif UX des actions groupées — 2026-10-04
- Corrige le panneau **Modification groupée** natif WordPress qui pouvait encore apparaître et être comprimé dans une colonne étroite par le tableau métier CallTracker.
- Désactive côté PHP les actions groupées natives du CPT `callink_campaign` afin qu elles ne puissent plus contourner le parcours métier sécurisé.
- Retire défensivement du DOM la zone native `.bulkactions` et la ligne `#bulk-edit` si un thème ou une extension WordPress les réinjecte.
- Déplace le bouton **Actions groupées** CallTracker directement dans la barre Recherche / filtres, à l emplacement attendu par l utilisateur.
- Rend le panneau CallTracker hors du tableau, pleine largeur, `box-sizing:border-box`, sans héritage de largeur de colonne ni scroll interne étroit.
- Conserve sans changement le moteur 1.11.29 : aperçu serveur, permission `calltracker/approve`, nonce, token à usage unique, empreinte d état, verrous et journalisation.
- Aucun changement Twilio, routage, schéma SQL, historique, CPL ou données de campagne.

## 1.11.29 — actions groupées guidées dans Campagnes — 2026-10-04
- Ajoute un bouton **Actions groupées** dans CallTracker AWM → Campagnes, activé seulement lorsqu’au moins une campagne est sélectionnée.
- Ajoute les actions courantes **Activer**, **Mettre en pause** et **Réattribuer** avec aperçu serveur avant écriture.
- Réutilise le moteur sécurisé `CallLink_Campaign_Bulk_Actions` existant : nonce, permission `calltracker/approve`, aperçu à usage unique, empreinte d’état, verrous concurrents et journal Core.
- Les actions sensibles **Archiver**, **Corbeille**, **Libérer Twilio** et **Supprimer définitivement** sont séparées dans une zone dédiée et conservent leur phrase de confirmation exacte.
- Les actions Activer / Pause sont idempotentes et ne touchent ni aux numéros Twilio, ni aux historiques, ni au routage. Une campagne archivée ne peut pas être réactivée par lot sans restauration explicite.
- La réattribution conserve le comportement existant : campagne, numéro, appels et formulaires suivent le client cible après validation serveur.
- Le panneau affiche avant exécution le nombre de campagnes, les historiques concernés, les numéros conservés/libérés, les avertissements et les blocages.
- La liste native WordPress d’actions en masse est masquée sur cette vue afin de garder un seul parcours métier guidé.
- Validation terrain 1.11.28 confirmée par l’exploitation : tri serveur, Historique total et vues technicien sont considérés fonctionnels.

## 1.11.28 — tri métier serveur + vues technicien — 2026-10-04
- Rend **Leads 30 j**, **Historique total** et **CPL** triables côté serveur sur l ensemble des campagnes, avec pagination conservée.
- Le tri Leads 30 j utilise appels entrants + formulaires des 30 derniers jours; Historique total utilise tous les appels + formulaires rattachés.
- Le tri CPL utilise le coût du mois courant et le volume de leads du mois, y compris la règle Capturia de la campagne.
- Ajoute les vues technicien **Toutes**, **À vérifier**, **Sans client** et **Sans numéro**.
- Mémorise la vue par utilisateur et la conserve pendant recherche, filtres et pagination.
- **À vérifier** regroupe erreurs de synchronisation, campagnes sans client et campagnes sans numéro principal.
- Aucun changement de schéma SQL, Twilio, routage, migration historique ou données réintégrées.

## 1.11.27 — historique total visible dans Campagnes — 2026-10-04
- Remplace la colonne redondante **Appels 30 j** par **Historique total** dans la liste Campagnes, tout en conservant **Leads 30 j** pour la lecture récente.
- Affiche pour chaque campagne le total cumulé avec le détail **appels + formulaires** afin que les données réintégrées plus anciennes que 30 jours restent immédiatement visibles.
- Ajoute dans le panneau Détails deux cartes distinctes : **Performance 30 jours** et **Historique total**.
- Calcule les métriques 30 jours et les totaux historiques dans les mêmes requêtes groupées par page afin d éviter des requêtes par campagne.
- Utilise l activité historique réelle comme dernière activité lorsqu aucune donnée récente n existe.
- Aucun changement de schéma BD, import, routage Twilio, CPL ou formulaires; les 214 appels historiques restants restent un écart connu non bloquant.

## 1.11.26 — réparation des formulaires historiques — 2026-10-04
- Corrige les formulaires Laravel où `from_email` contenait l’adresse technique du site (`no-reply@...`, `email@...`) au lieu du courriel réel du prospect.
- Extrait du contenu historique le vrai **nom**, **courriel**, **téléphone** et la **page source** lorsque ces données sont présentes.
- Utilise `web_form_capture_url` de la campagne legacy comme repli pour la page source lorsque l’ancien courriel ne contient pas `URL de la page`.
- Le dashboard applique l’extraction à l’affichage immédiatement, même avant la réparation persistante de la base.
- Ajoute dans Migration une réparation ciblée des **44 712 formulaires historiques**, par lots de 100, reprenable et sans retoucher les appels/Twilio.
- Préserve l’expéditeur technique original dans le payload interne `_legacy_sender_email` sans l’afficher comme donnée du prospect.
- Exclut les campagnes en corbeille du mapping actif lors des prochaines réconciliations; leur historique reste archivé par `legacy_campaign_id`.
- Corrige l’état final de migration : une exécution terminée avec erreurs n’est plus affichée « Prête à lancer » mais « Terminée avec N erreur(s) ».
- Validation hors ligne de l’extracteur sur les 44 712 formulaires : 40 105 courriels clients, 38 648 téléphones et 36 461 pages sources récupérables avec les règles prudentes.

## 1.11.25 — démarrage réellement instantané + lots courts — 2026-10-03
- Corrige le cas terrain où **Préparation…** s affichait mais la première requête serveur ne revenait toujours pas.
- Le clic de démarrage ne parcourt plus les 115 fichiers, ne compte plus les tables historiques et n énumère plus tous les tenants : il valide uniquement les trois petits manifestes puis crée la session.
- Le navigateur reçoit un accusé de démarrage avant tout travail lourd; le premier fichier est ensuite vérifié par SHA-256 dans la requête de lot.
- Réduit le lot d écriture de 500 à **100 lignes** pour rester sous les limites PHP/HTTP du serveur et rendre la progression visible.
- Optimise les cartes utilisateurs/campagnes par requêtes SQL groupées au lieu d une série de lectures de métadonnées WordPress.
- Les réponses intermédiaires n exécutent plus de `COUNT(*)` sur les tables après chaque lot; les compteurs exacts sont recalculés à la fin ou au rechargement.
- Ajoute un timeout navigateur explicite : en cas de serveur bloqué, l interface affiche une erreur et le curseur reste reprenable.
- Conserve SHA-256 avant écriture de chaque fichier source, déduplication, rattachement tenant et enrichissements existants.

## 1.11.24 — démarrage immédiat de la réintégration — 2026-10-03
- Corrige le bouton **Démarrer la réintégration** qui pouvait sembler figé pendant que 115 fichiers historiques étaient relus et hachés avant le premier retour AJAX.
- Remplace ce pré-scan lourd par un précontrôle rapide : cohérence des manifestes, présence/taille des 115 fichiers, totaux attendus et propriétaires legacy WordPress.
- Conserve la sécurité SHA-256 : chaque fichier source est vérifié intégralement juste avant le lot qui l importe.
- Affiche immédiatement **Préparation…** au clic puis la progression **Lot source X / 115**, appels, formulaires, lignes traitées et erreurs.
- La migration reste idempotente, reprenable, par lots de 500 et ne touche pas au routage Twilio, aux numéros, aux campagnes ou au CPL.

## 1.11.23 — réintégration historique contrôlée — 2026-10-02
- Ajoute dans **Validation et santé → Rapprochement Laravel → WordPress** un assistant de réintégration pour les **69 306 appels** et **44 712 formulaires** assignés de l’export historique.
- Vérifie avant démarrage les 115 lots historiques par SHA-256 et nombre exact de lignes; refuse l’import si le paquet ne correspond plus à l’export source.
- Importe par lots de 500 avec curseur persistant : fermer/recharger la page ne recommence pas la migration et aucune opération longue n’est nécessaire dans une seule requête.
- Rend la réintégration idempotente grâce aux `legacy_id` et `submission_uid`; les relances mettent à jour/réconcilient sans créer de doublons.
- Le propriétaire WordPress actuel de la campagne reste la frontière de tenant; à défaut, le propriétaire de la campagne dans l’export Laravel sert de repli, puis le client de la ligne source.
- Conserve les enrichissements déjà présents dans WordPress : Recording SID/URL/durée, écoute, child Call SID, payload structuré, téléphone/page de formulaire et autres données ajoutées après le premier import.
- Permet de conserver l’historique d’une campagne qui n’a plus de fiche active : `campaign_post_id=0`, `legacy_campaign_id` conservé et propriétaire client toujours rattaché.
- Journalise préparation, fin de lot, erreurs et clôture dans Core AWM; expose insertions, mises à jour, inchangés, erreurs, réattributions tenant et archives sans campagne active.
- Ne touche ni au routage Twilio, ni aux numéros, ni aux campagnes, ni au CPL pendant cette réintégration historique.
- Corrige aussi le blocage critique détecté par l audit 4.5.347 : ajoute `upload_admin_file()` et `save_bytes()` pour que le wizard Hub puisse réellement téléverser/remplacer les MP3 disclosure/publicité dans le stockage privé CallTracker.

## 1.11.22 — lecteur recordings Twilio / HTTP Range — 2026-10-02
- Corrige le lecteur qui restait à `0:00 / 0:00` malgré un appel et un Recording SID valides.
- Suit jusqu à 5 redirections du média Twilio et conserve le téléchargement côté serveur AWM.
- Ajoute le support des plages HTTP `bytes=start-end` avec réponses 206/416 conformes pour Chrome et les lecteurs HTML5.
- Passe les lecteurs en `preload=metadata` pour charger la durée réelle avant lecture.
- Ajoute un état visuel de lecture (chargement, prêt + durée, lenteur, erreur) sans exposer Twilio au navigateur.
- Aucun changement de schéma BD, routage, attribution d appels, formulaires ou CPL.

## 1.11.21 — synchronisation manuelle des données — 2026-10-02
- Ajoute **Synchroniser** sur chaque carte campagne et **Synchroniser le client** au-dessus de ses campagnes.
- Importe/réconcilie les appels Twilio du numéro suivi pour la période affichée, en conservant le vrai timestamp, statut et durée.
- Rattache les appels locaux au bon `campaign_post_id` par `legacy_campaign_id` puis, lorsque le numéro est unique, par numéro suivi normalisé.
- Rattache les formulaires orphelins au mapping exact site + source + identifiant et actualise les inventaires Hub Client/Connector des sites concernés.
- Affiche un retour de synchronisation avec appels importés/mis à jour/rattachés, formulaires rattachés et sites actualisés, puis recalcule automatiquement les KPI.
- La synchronisation client traite uniquement les campagnes du client ouvert, séquentiellement; aucune synchronisation globale de flotte n est lancée.
- La réconciliation des appels locaux s exécute avant l import Twilio afin de réparer les rattachements même si les identifiants Twilio sont temporairement indisponibles.

## 1.11.20 — correctifs dashboard terrain — 2026-10-02
- Le détail Appels expose le lecteur sécurisé dès qu un Call SID Twilio est disponible, même sans `recording_sid` local.
- À la première lecture, CallTracker cherche les recordings Twilio par Child Call SID puis Call SID, choisit le recording valide, persiste son SID/durée et sert le MP3 côté serveur.
- Le détail Formulaires affiche tous les champs du payload directement : contact, coordonnées, message, champs personnalisés, UTM et métadonnées utiles.
- Les anciens formulaires e-mail affichent également le contenu nettoyé complet lorsque nécessaire.
- Le dashboard est déclaré comme écran CallTracker dans Core 4.5.272 afin d utiliser le header CallTracker AWM au lieu du header Hub.

# 1.11.19 - 2026-10-02

## Ajouté
- Tableau de bord CallTracker centré sur le client : Client -> Campagnes -> Sites/domaines -> Appels/Formulaires.
- 8 KPI compacts et responsive : clients actifs, campagnes actives, appels entrants, formulaires, leads, répondus, manqués, CPL moyen.
- Filtres par client, campagne et période, plus recherche rapide locale.
- Dépliage par client et cartes campagne avec sites exacts, numéro, formulaires configurés, performance et CPL.
- Panneau Appels avec lecture MP3 sécurisée via le serveur AWM, sans exposer les identifiants Twilio.
- Panneau Formulaires avec moteur, identifiant, contact, page et contenu des soumissions.
- Raccourci Tableau de bord ajouté à l’écran Campagnes existant.

## Compatibilité
- Les tables `callink_calls`, `callink_forms`, `callink_route_attempts`, le CPT `callink_campaign` et le moteur CPL restent inchangés.
- Aucun schéma de base de données supplémentaire.

# 1.11.18 — diagnostic Elementor dans l'assistant formulaires — 2026-10-02
- Conserve et affiche le diagnostic `elementor_scan` remonté par Hub Client.
- Après synchronisation d'un site sans formulaire détecté, indique si Elementor Pro est actif et combien de documents Elementor ont réellement été analysés.
- Le bouton **Synchroniser les formulaires** reste ciblé sur un seul WordPress et ne déclenche aucune rafale flotte.

# 1.11.17 — assistant site → synchroniser → choisir — 2026-10-01
- Nouveau parcours en 3 étapes : choisir le WordPress, synchroniser ses formulaires, sélectionner plusieurs formulaires puis enregistrer.
- Le bouton « Synchroniser les formulaires » cible uniquement le site choisi et réutilise les protections anti-rafale Core.
- Ajoute Contact Form 7 comme troisième moteur natif aux côtés de Gravity Forms et Elementor Pro Forms.
- Les associations restent multi-sites et multi-formulaires; racine et /region restent deux WordPress distincts.
- La saisie manuelle reste un secours, pas le parcours principal.

# 1.11.16 — sauvegarde fiable + détection explicite — 2026-10-01
- Corrige la persistance des lignes multi-formulaires avec un payload JSON canonique par ligne; les tableaux historiques restent pris en charge en repli.
- Ajoute un bouton local « Enregistrer les formulaires » et bloque uniquement les lignes incomplètes/doublons avant soumission.
- Corrige le champ de message de succès qui lisait une ancienne clé POST.
- Affiche les sites Connector actifs même si leur premier inventaire formulaires n est pas encore revenu.
- Ajoute « Actualiser la détection » : Core interroge les sites séquentiellement, sans rafale, puis recharge la liste.

# 1.11.15 — UX formulaires détectés multi-sites — 2026-10-01
- CallTracker affiche un parcours 1. Site WordPress → 2. Moteur → 3. Formulaire avec choix détectés automatiquement.
- Une campagne accepte plusieurs WordPress et plusieurs formulaires; les chemins comme /region restent des sites distincts.
- Ajoute un résumé Sites/Formulaires/Gravity/Elementor et une détection visuelle des doublons avant sauvegarde.
- La saisie manuelle reste disponible comme secours si l inventaire du site n est pas encore remonté.
- L inventaire des formulaires est stocké par site Connector et n ajoute aucune requête réseau dédiée : il voyage avec l inventaire Hub Client existant.

# 1.11.14 — 2026-10-01

- Une campagne peut maintenant couvrir plusieurs installations WordPress/domaines, y compris des WordPress distincts sur le même domaine comme `/` et `/region`.
- Chaque formulaire associé porte désormais son **Site WordPress exact** + sa source + son identifiant; les chemins sont conservés pour distinguer les installations.
- UX du bloc Formulaires réorganisée en lignes `Site WordPress → Source → Formulaire`, avec ajout/retrait sans écraser les autres sites de la campagne.
- Compatibilité conservée avec les mappings historiques sans site explicite (`tous les sites liés`).

# 1.11.13 — 2026-10-01

- Refonte UX du bloc Formulaires : plusieurs formulaires par campagne, mélange Elementor + Gravity Forms, ajout/retrait par ligne.
- Gravity Forms est présenté en premier avec un libellé clair « ID Gravity Forms » et un exemple #1 afin d éviter de laisser Elementor sélectionné par erreur.
- Le mapping central est maintenant une liste dédupliquée; le premier mapping reste publié en compatibilité avec les anciens Hub Client.
- Les options techniques du formulaire AWM intégré sont déplacées dans « Options avancées » pour simplifier le parcours stagiaire.

# 1.11.12 — 2026-10-01

- UX Campagnes Appels / Formulaires.
- Ajoute les onglets Appels, Formulaires et Tout afficher; permet de choisir Elementor Pro ou Gravity Forms directement dans la campagne et publie le mapping au Hub Client.

## 1.11.11 — 2026-09-30
- Accepte la source de conversion `hub_client_gravityforms` provenant de Hub Client 1.14.4.
- Les soumissions Gravity Forms restent associées au client et à la campagne CallTracker par le même contrat sécurisé existant.
- Aucun changement au moteur d appels, au routage ni à l UX Campagnes 1.11.10.

## 1.11.10 — 2026-09-30
- Barre Campagnes desktop verrouillée sur une seule rangée : recherche, action groupée, Appliquer, Client, Statut, Source et Filtrer.
- Suppression des contraintes WordPress qui pouvaient forcer `p.search-box` sur une ligne séparée (`position`, `clear`, largeur).
- Le conteneur `alignleft actions` passe en `display: contents` afin que tous les contrôles partagent le même flex parent.
- Largeurs resserrées progressivement à 1500 px et 1100 px; repli multi-ligne réservé au mobile/tablette étroite.
- Pagination supérieure reste masquée; pagination inférieure inchangée.

## 1.11.9 — 2026-09-30
- Force la barre Campagnes desktop sur une seule ligne : recherche, actions groupées, filtres client/statut/source et boutons restent alignés horizontalement.
- Compresse proprement les largeurs et espacements à 1500 px et raccourcit le bouton de recherche à « Rechercher » sans casser les libellés principaux.
- Retire la pagination WordPress du haut de la liste (compteur + flèches) afin d éliminer le bloc isolé sous les filtres; la pagination du bas reste disponible.
- Conserve un repli responsive sous 1100 px et l empilement mobile existant.
- Aucun changement de données, Twilio, routage, Capturia, Google Ads ou CPL.

# Changelog — CallTracker AWM

## 1.11.8 — 2026-09-30
- Affiche le **nom complet de la campagne** et le **nom complet du client** avec retour à la ligne propre au lieu d'une ellipse trop agressive.
- Supprime la colonne/badge texte de statut afin de libérer de la largeur pour Campagne et Client.
- Remplace le statut par un point unique à côté du nom : **vert = actif**, **jaune = pause**.
- Rend ce point cliquable pour basculer Actif ↔ Pause sans ouvrir la campagne, avec nonce WordPress, `edit_post`, journal AWM et retour visuel immédiat.
- Maintient **CPL** visible en mode compact jusqu'aux très petites largeurs et rend l'en-tête du tableau sticky pour identifier clairement les valeurs `—`.
- Conserve les favicons 1.11.7, le tableau sans overflow horizontal, Twilio, Capturia, Google Ads, routage et formule CPL inchangés.

## 1.11.7 — 2026-09-30
- Supprime le défilement horizontal du tableau Campagnes en desktop : largeur fixe à 100 %, `table-layout: fixed`, colonnes compactes et contenu tronqué proprement plutôt que poussé hors fenêtre.
- Ajoute un mode de densité **Compact / Détaillé** mémorisé par navigateur. Compact devient le choix par défaut sous 1680 px; le mode Blocs reste prioritaire sur mobile.
- Masque progressivement les colonnes secondaires à 1500 / 1280 / 1100 px afin de conserver Campagne, Client, Numéro, Routage, Statut et activité dans la fenêtre sans barre de déplacement en bas.
- Réduit les actions de ligne en largeur intermédiaire; les actions secondaires restent accessibles dans le panneau de détail.
- Remplace la lettre du client par sa **favicon réelle** : favicon manuelle Hub, favicon détectée par le moteur de style, puis `/favicon.ico` du site client en repli. Si aucune image ne charge, une icône de site neutre est affichée, jamais une initiale.
- Conserve Twilio, Capturia, Google Ads, CPL, routage, modèles et données inchangés.

## 1.11.6 — 2026-09-30
- Force les cinq KPI de la page **Campagnes** sur une seule rangée en desktop et laptop.
- Remplace les cassures 3+2 / 2+2+1 par une compression contrôlée puis un défilement horizontal tactile sur petits écrans.
- Réduit et harmonise hauteur, padding et typographie des cartes KPI avec `clamp()` pour conserver la lisibilité à 1366 px / 1080p.
- Réorganise la barre Recherche / filtres / actions / pagination avec une grille responsive puis un empilement propre sur mobile.
- Protège le tableau métier avec une largeur minimale afin d'éviter les retours de ligne excessifs dans Client, Numéro et Routage; le conteneur devient scrollable au besoin.
- Conserve le mode **Blocs**, le détail rapide, les données, le routage Twilio, Capturia, Google Ads et le CPL inchangés.

## 1.11.5 — 2026-09-30
- Refonte complète du listing **Campagnes** en tableau métier professionnel et responsive, sans remplacer le CPT historique ni son éditeur.
- Ajoute les KPI en tête : campagnes actives, clients couverts, leads 30 jours, CPL pondéré du mois courant et alertes de routage/synchronisation.
- Ajoute les colonnes Client associé, Source/type, Numéro principal, Routage/équipe, Statut, Leads 30 j, Appels 30 j, CPL, Dernière activité et actions compactes.
- Ajoute les filtres client, statut et source directement dans la liste Campagnes.
- Ajoute un basculement **Tableau / Blocs** mémorisé par navigateur; le mode Blocs devient automatiquement prioritaire sur petit écran.
- Ajoute un panneau de détail rapide d une campagne avec client, source, numéro, routage et performance 30 jours.
- Conserve les données, le routage Twilio, le calcul CPL, Capturia, Google Ads, les modèles de routage et les URLs d édition existantes.

## 1.11.4 — 2026-09-30
- Ajoute les filtres 7 / 30 / 90 jours aux statistiques de routage de chaque campagne.
- Ajoute un export CSV UTF-8 détaillé avec résumé de campagne et chaque tentative Twilio.
- Prépare le prochain calcul de temps avant réponse sans l inventer : `DialCallDuration` mesure la conversation et ne doit pas être confondu avec le temps de sonnerie.
- Conserve la télémétrie additive introduite en 1.11.3; aucun historique antérieur n est inventé.
- Aucun changement de formule CPL, Capturia, Google Ads, modèles de routage ou chaîne Twilio.

## 1.11.3 — 2026-09-29
- Ajoute une journalisation SQL additive de chaque tentative de routage Twilio séquentiel : étape, destination, statut, durée et appel enfant.
- Ajoute dans **Routage avancé** un tableau **Performance du routage — 30 jours** avec appels routés, taux de réponse, récupération par secours et appels sans réponse.
- Détaille les performances par étape : tentatives, réponses, taux, durée moyenne, sans réponse et occupé.
- Enregistre sur l appel répondu l étape, le libellé et la destination qui ont effectivement décroché.
- Les statistiques commencent à partir de 1.11.3; aucun historique antérieur n est inventé ou recalculé.

## 1.11.2 — 2026-09-29

- Corrige le piège UX observé en production : charger un modèle de routage applique maintenant immédiatement l'équipe à la campagne au lieu d'attendre un enregistrement WordPress séparé.
- Ajoute **Appliquer l'équipe maintenant** pour rendre les modifications manuelles actives sans enregistrer toute la fiche.
- Le simulateur utilise désormais les valeurs actuellement visibles dans le formulaire, même avant sauvegarde, et affiche explicitement les étapes 1 → 2 → 3 avec la condition « si sans réponse ».
- Ajoute un état visuel lorsque des modifications de routage sont présentes dans le formulaire mais pas encore appliquées aux appels réels.
- Journalise l'application immédiate via `calltracker_routing_team_applied_live`.

## 1.11.1 — 2026-09-29
- Ajoute des modèles de routage réutilisables directement dans le bloc « Routage avancé — équipe et simulateur ».
- Un modèle copie jusqu à cinq destinations avec libellé, numéro, priorité, activation et délai de sonnerie; la campagne reste indépendante après chargement.
- Permet d enregistrer, charger et supprimer jusqu à vingt modèles globaux avec permissions CallTracker et nonce WordPress.
- Le routage Twilio séquentiel 1.11.0, le CPL, Capturia, Google Ads et les appels existants restent inchangés.

## 1.11.0 — 2026-09-29

- Ajoute le Lot C phase 2 pour le routage entrant : jusqu à cinq destinations de débordement nommées et priorisées par campagne.
- Chaque destination de secours possède son propre délai de sonnerie de 10 à 60 secondes.
- Étend la route TwiML `routing-next` pour parcourir une chaîne séquentielle par index, tout en conservant la compatibilité avec les callbacks `primary/overflow` de 1.10.x.
- Ajoute un simulateur non destructif dans l éditeur de campagne pour tester une date/heure dans le fuseau de campagne et afficher la route exacte sans contacter Twilio.
- Conserve `_callink_overflow_destination` comme premier secours de compatibilité avec Hub Client et les anciennes campagnes.
- Étend Validation et santé et l empreinte d approbation aux membres de l équipe de débordement.
- Refuse les doublons et les collisions avec les destinations principale et hors-heures avant toute écriture.
- Aucun changement de tables, appels, CPL, Google Ads, Capturia, numéros ou secrets Twilio.

---

## 1.10.9 - Capturia branchement par clé API uniquement - 2026-09-25
- Le parcours ne suppose plus aucun accès au tableau de bord Capturia : l administrateur AWM colle uniquement la clé fournie par le client.
- `GET /v1/me` mémorise le compte détecté, le preset, les scopes et l expiration de la clé sans exposer le secret.
- `GET /v1/contacts?limit=1` devient le test obligatoire : `contacts:read` est le seul droit minimal nécessaire pour calculer des leads/CPL.
- `tags:read` devient recommandé mais non bloquant : si absent, la connexion reste valide et AWM explique précisément la permission manquante.
- L interface affiche les permissions détectées et distingue droits requis (`contacts:read`) des droits recommandés/optionnels (`tags:read`, `pipeline:read`, `bookings:read`).
- Protection anti-surcomptage : sans tag, les contacts ne peuvent pas entrer dans le CPL tant qu un administrateur ne confirme explicitement que tous les contacts accessibles par cette clé appartiennent à la campagne.
- L option d inclusion Capturia dans le CPL est désormais désactivée par défaut sur une nouvelle liaison et exige une attribution sûre.
- Aucune écriture Capturia ajoutée; le connecteur reste GET-only et serveur-à-serveur.

## 1.10.8 - Validation CPL Capturia et pipeline lecture seule - 2026-09-25
- Ajout d une synchronisation optionnelle `GET /v1/pipeline/stages` + `GET /v1/pipeline/deals`, strictement en lecture, après la synchronisation des contacts Capturia.
- Les opportunités sont rattachées uniquement aux `contact_id` déjà importés pour la campagne/tag AWM; les compteurs globaux Capturia ne sont jamais utilisés pour attribuer une campagne.
- Nouvel état local `callink_capturia_state` par campagne/contact : présence du tag + état pipeline courant.
- Réconciliation complète quotidienne du tag Capturia : un contact supprimé ou retiré du tag n est retiré du CPL local qu après un scan complet réussi; aucune purge n est faite sur un scan partiel ou en erreur.
- Le panneau Capturia montre le mois courant : leads importés, leads comptés dans le CPL, opportunités actuelles, valeur pipeline et répartition par étape.
- Le test de connexion vérifie aussi les capacités `pipeline:read` et `bookings:read`; une permission optionnelle absente ne bloque jamais l import des contacts ni le CPL.
- Les rendez-vous restent en diagnostic uniquement tant qu un lien campagne/contact fiable n est pas confirmé dans le payload réel du premier client.
- Aucune écriture n est envoyée à Capturia et la formule CPL reste inchangée.

## 1.10.7 - Capturia lecture seule et CPL - 2026-09-24

- Ajoute une intégration Capturia directement sur les campagnes CallTracker existantes; aucun Hub Client ni plugin AWM n est requis sur la landing page du client.
- Stocke la clé API Capturia chiffrée avec `AWM_Core_Vault`, dans un contexte propre à la campagne, et ne la réaffiche jamais.
- Valide la connexion avec `GET /v1/me`, charge les tags avec `GET /v1/tags` et synchronise les contacts via `GET /v1/contacts` uniquement.
- Permet de filtrer les contacts par tag Capturia afin de rattacher les bonnes statistiques à la bonne campagne AWM.
- Ajoute un import historique progressif puis une synchronisation incrémentale automatique toutes les 15 minutes, avec curseur opaque Capturia, journalisation et conservation du request ID en cas d erreur.
- Enregistre chaque contact avec un `submission_uid` stable et `source=capturia`; les resynchronisations mettent à jour le même lead au lieu de le dupliquer.
- Sépare dans le CPL les formulaires AWM et les leads Capturia; Capturia n est inclus dans le dénominateur que si la campagne l autorise explicitement.
- Suspend la synchronisation Capturia si le client CRM est inactif et conserve les données historiques sans suppression.
- Validation statique possible sans clé réelle; la validation terrain de la portée de la clé et du tag reste à effectuer sur le premier client Capturia.

## 1.10.6 - Refonte UX Google Ads / CPL - 2026-09-21

- Refonte complete de la page **CallTracker AWM -> Google Ads** pour suivre le shell visuel AWM en Light et Dark.
- Ajoute un en-tete acquisition/CPL avec etats OAuth, MCC et synchronisation visibles immediatement.
- Remplace le rendu WordPress brut des champs par des cartes, champs, boutons, tableaux et etats coherents avec CallTracker.
- Ameliore fortement le responsive mobile/tablette, notamment la liste des MCC et les actions.
- Aucun changement OAuth, API Google Ads, calcul CPL, table SQL ou historique : correctif UX uniquement.

## 1.10.5 - Interface Google Ads restaurée dans CallTracker - 2026-09-21

- Ajoute une page **CallTracker AWM -> Google Ads** directement depuis le module, sans dépendre de Hub AWM -> Réglages.
- Corrige la régression où Hub AWM 4.5.57 masquait l ancien écran `callink-google-ads` alors que le moteur Google Ads 1.10.4 restait actif.
- Permet d enregistrer OAuth Client ID / Secret, les deux MCC ou davantage, puis de connecter Google Ads.
- Ajoute un test de MCC qui liste les comptes clients accessibles avant toute association de campagne.
- Conserve le moteur CPL multi-MCC 1.10.4, l historique, la formule CPL et les synchronisations automatiques.
- Le Developer Token historique reste compatible; depuis le 9 septembre 2026, Google rattache l accès API au projet Google Cloud des identifiants OAuth.

## 1.10.4 - Google Ads CPL multi-MCC automatise - 2026-09-21

- Utilise Google Ads API v25 pour recuperer `metrics.cost_micros` par MCC, compte et campagne.
- Le Developer Token devient facultatif dans le moteur: si un ancien token existe il reste envoye pour compatibilite, sinon l acces repose sur le projet Google Cloud lie aux identifiants OAuth.
- Conserve plusieurs MCC dans une seule integration CallTracker et utilise le bon `login-customer-id` par campagne.
- Ajoute la devise Google Ads, le `request-id`, la source et la fraicheur de synchronisation au CPL.
- Ajoute une synchronisation automatique par petits lots toutes les 15 minutes pour le mois courant et le mois precedent, sans longue requete bloquante.
- Une erreur Google Ads ne remplace jamais un investissement valide par zero; la campagne passe en etat `stale` avec la derniere erreur conservee.
- Etend la table CPL de facon additive avec source, devise, statut, date de synchro et metadonnees de source.
- Le mode manuel et l historique Laravel restent disponibles sans migration destructive.
- Les futurs profils OAuth multiples restent prevus seulement si les deux MCC exigent des identites Google differentes.

## 1.10.3 — Pulse v2 routage — 2026-09-12

- Le score Health CallTracker pénalise uniquement les erreurs de synchronisation/routage connues.
- Les campagnes et Twilio restent non modifiés automatiquement; le score sert au triage.

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

- Expose au Core un pulse campagnes actives / brouillons / erreurs de synchronisation routage.
- Le pulse reste strictement descriptif et ne déclenche aucune opération Twilio.

## 1.10.1 — 2026-09-11
- CallTracker respecte désormais le statut opérationnel canonique de CRM AWM.
- Un client inactif n'est plus éligible aux opérations CallTracker, tout en conservant campagnes, appels, enregistrements et historique.
- La réactivation CRM restaure l'éligibilité selon le réglage CallTracker déjà enregistré.

## 1.10.0 — 2026-09-02

- Structure le parcours client **CallTracker → Nouveaux services → Nouveau funnel → Configuration du numéro → Formulaire/Webhook → Routage**.
- Sépare définitivement la commande commerciale de l exécution technique : CRM crée et possède le service Funnel à 10 $/mois; CallTracker prépare la campagne technique.
- Un nouveau funnel commence en état **configuration requise** et n active pas la facturation récurrente tant qu aucun numéro n a été acheté et attribué.
- L achat du numéro réutilise le service CRM et la campagne préparés, revalide la disponibilité Twilio juste avant la transaction puis active le service CRM après succès.
- Un échec Twilio laisse le funnel en configuration pour permettre une nouvelle tentative sans recréer un abonnement; un achat potentiellement accepté mais incomplet est conservé pour vérification afin d éviter un double achat.
- Étend le routage modifiable par Hub Client : destination principale, fuseau, horaires, fermetures, destination hors heures, débordement séquentiel, délai et Message 2.
- Conserve toutes les validations de propriété côté serveur et journalise séparément les modifications effectuées depuis Hub Client.

## 1.9.9 — 2026-09-02

- Ajoute un webhook HTTPS unique et secret pour chaque Funnel CallTracker.
- Active automatiquement la structure de formulaire du funnel après achat du numéro et génère son URL de webhook sans exposer de secret Twilio.
- Accepte les envois POST JSON ou formulaire de plateformes externes et reconnaît les champs courants nom, courriel, téléphone, message et URL de page.
- Ajoute une protection anti-rejeu courte et un identifiant idempotent lorsque la plateforme fournit `submission_id` ou un identifiant de requête.
- Les formulaires reçus sont enregistrés dans l historique CallTracker existant et alimentent immédiatement Leads et CPL du bon funnel.
- Ajoute un test client non destructif qui vérifie campagne, jeton et stockage sans créer de faux lead.
- Conserve le dernier instant de réception par funnel pour faciliter le diagnostic dans Hub Client.

## 1.9.8 — 2026-09-02

- Ajoute la recherche sécurisée de numéros Twilio pour Hub Client sans exposer les identifiants ni les URL d API.
- Permet au client CallTracker autorisé d acheter un numéro et de créer son Funnel directement depuis son Hub.
- Chaque achat crée une campagne CallTracker, attribue le numéro et lie un service CRM Funnel à 10 $/mois.
- Le service est préparé avant l appel Twilio et supprimé automatiquement si aucun achat externe n a eu lieu.
- Si Twilio accepte l achat mais qu une étape locale échoue, la campagne est conservée pour empêcher un double achat et Alliance reçoit un état à vérifier.
- L inventaire des numéros est invalidé après achat afin de refléter immédiatement le nouveau numéro.

## 1.9.7 — 2026-09-02

- Livre la phase 1 du **Lot C — Routage avancé**.
- Ajoute des horaires hebdomadaires par campagne dans le fuseau déjà géré par CallTracker.
- Ajoute les fermetures spéciales / jours fériés au format YYYY-MM-DD.
- Ajoute une destination hors heures facultative; si elle est vide, CallTracker ferme proprement l appel au lieu de transférer vers une mauvaise route.
- Ajoute une destination de débordement séquentielle après non-réponse, occupé ou échec de la première destination.
- Ajoute un délai de sonnerie configurable de 10 à 60 secondes.
- Ajoute un aperçu de la route effective dans Hub : état Ouvert/Fermé, heure locale, destination actuelle et débordement.
- Ajoute la route Core `callink/v1/routing-next` signée par Twilio pour enchaîner le secours sans sonner deux destinations en parallèle.
- Étend Validation et santé : empreinte, horaire, destination hors heures, débordement, délai et tests requis.
- Les équipes, priorités, stratégies multi-tentatives, modèles réutilisables et tests simulés restent dans le Lot C phase 2.

# Changelog — CallTracker AWM

## 1.9.6 — 2026-08-25
- Ajoute la bascule globale de l’ancienne plateforme dans **Validation et santé**.
- Resynchronise par lots tous les numéros des campagnes actives et les numéros encore actifs dans l’export legacy retrouvés localement vers le webhook entrant AWM.
- Reprend également les numéros dont les appels entrants sont désactivés et les numéros actifs legacy retrouvés sur une campagne locale maintenant inactive; AWM garde le webhook puis bloque leur transfert.
- Refuse la finalisation si un numéro actif de l’export legacy ne correspond à aucune campagne locale, afin de ne jamais laisser un numéro oublié sur l’ancienne plateforme.
- Résout les Phone Number SID manquants, retire `VoiceFallbackUrl` et `VoiceApplicationSid`, puis relit Twilio pour confirmer la reprise.
- Ajoute progression, aperçu, erreurs par campagne, reprise sans popup et journal Core.
- Ajoute le verrou **BASCULE AWM** qui transforme Laravel en référence historique et bloque les nouveaux imports migration/CPL.
- Ajoute une réouverture exceptionnelle explicite pour les imports historiques.
- Conserve Lot C Routage avancé comme prochaine implémentation et référence l’accès API Google approuvé pour le futur Lot E CPL/Google Ads.

---

## 1.9.5 — 2026-08-25
- Corrige les campagnes existantes dont le numéro de réception a été modifié : la sauvegarde déclenche maintenant une resynchronisation du webhook entrant Twilio vers AWM.
- Vérifie le Phone Number SID; s'il manque ou ne correspond plus au numéro de campagne, le SID est recherché dans le compte Twilio configuré puis rattaché à la campagne.
- Priorité de destination explicite : numéro de transfert de campagne, puis numéro du client en fallback.
- Une modification du numéro client resynchronise automatiquement les campagnes qui utilisent ce fallback et n'ont pas d'override propre.
- Ajoute un bloc « Routage entrant Twilio » dans l'éditeur avec destination effective, dernière destination synchronisée, date, erreur éventuelle et bouton de resynchronisation manuelle.
- Conserve une empreinte de configuration afin de ne contacter Twilio que lorsqu'un élément critique de routage change.
- Journalise les synchronisations et échecs dans Core AWM sans empêcher l'enregistrement local de la campagne.
- Exige Core AWM 4.5.43.
- Utilise Hub AWM 4.5.15 pour empêcher le Heartbeat WordPress de déclencher le loader plein écran toutes les ~30 secondes dans l’éditeur.

## 1.9.4 — 2026-08-25

- Retire l'autosave WordPress natif de l'éditeur interne `callink_campaign` afin d'éviter le dialogue bloquant « Connexion perdue » et la sauvegarde locale navigateur hors du contrat AWM.
- Conserve Heartbeat pour les verrous/session, mais affiche l'état de connexion directement dans la barre **Enregistrer la campagne**.
- Affiche **Connexion active**, **Hors ligne — reconnexion automatique** ou **Connexion WordPress instable — enregistrement manuel disponible** sans modal navigateur.
- Le bouton d'enregistrement n'est désactivé que lorsque le navigateur est réellement hors ligne; une alerte Heartbeat seule n'empêche pas une tentative manuelle.
- Supprime les notices natives `lost-connection` / stockage local lorsqu'elles sont injectées dans l'éditeur de campagne.
- Exige Core AWM 4.5.42 et Hub AWM 4.5.14 pour l'expérience complète.
- Référence le correctif dans la roadmap sans marquer les validations Twilio terrain comme terminées.

---

## 1.9.3 — 2026-08-25

- Ajoute un registre persistant d idempotence pour les callbacks Twilio de statut et d enregistrement.
- Détecte les rejeux et empêche les doubles écritures sans bloquer les retries légitimes des routes TwiML.
- Empêche les statuts hors ordre de faire régresser un appel grâce à `SequenceNumber` et aux états monotones.
- Ajoute une file de reprise locale courte pour erreurs transitoires, cinq tentatives et un état échec définitif visible dans Validation et santé.
- Évite de rejouer les erreurs 4xx déterministes.
- Normalise appels et formulaires vers un temps UTC canonique et calcule les périodes CPL dans le fuseau de chaque campagne.
- Retire l URL Twilio brute du contrat client et passe la lecture des enregistrements par un proxy sécurisé Core/Hub Client.
- Exige Core AWM 4.5.41; l expérience client complète utilise Hub Client AWM 1.8.7.
- Met à jour roadmap et documentation sans marquer les validations terrain comme terminées.

---

## 1.9.2 — 2026-08-25

- Ajoute le centre **Validation et santé** accessible depuis Hub AWM.
- Compare les compteurs de migration attendus et importés pour clients, campagnes, numéros, appels, formulaires et périodes CPL, en tenant compte des exclusions persistantes.
- Analyse les doublons, orphelins et incohérences de propriétaire afin de faire ressortir les exceptions avant clôture.
- Ajoute un diagnostic par campagne : client, numéro, SID Twilio, affectation, webhook entrant, destination, fuseau horaire, Message 1, Message 2, Dialer, enregistrement et dernière activité.
- Ajoute un parcours de tests guidés pour la configuration, l’appel entrant, la destination, le CPL, le Dialer sortant, l’enregistrement et les messages audio selon les réglages actifs.
- Permet d’approuver une campagne seulement après validation explicite; l’approbation est liée à une empreinte SHA-256 des paramètres critiques et devient périmée si ceux-ci changent.
- Ferme l’exposition client du CPL par défaut : Core et Hub Client n’affichent que les campagnes approuvées, avec un état **CPL en validation** pour les autres.
- Ajoute une clôture de migration signée et réversible après approbation des campagnes actives; la clôture est refusée lorsque des exceptions bloquantes subsistent ou qu’une campagne active reste non approuvée; les campagnes inactives peuvent être revues séparément pour leur CPL historique.
- Remplace les confirmations navigateur natives des principaux flux CallTracker actifs par des confirmations AWM intégrées : inventaire de numéros, achats/réservations, campagnes, imports, CPL, Twilio, Google Ads, audio et historique.
- Journalise les validations, approbations, réouvertures et clôtures dans Core AWM.
- Exige Core AWM 4.5.39, Hub AWM 4.5.13 et Hub Client AWM 1.8.6 pour l’expérience complète.

---

## 1.9.1 — 2026-08-24

- Ajoute un marqueur de résultat explicite pour les opérations natives de campagne : corbeille, restauration, suppression définitive et enregistrement groupé.
- Ces résultats sont consommés par le loader AWM au lieu d’un bandeau WordPress.
- Le mécanisme reste compatible avec l’action native « Annuler » extraite par Hub lorsque WordPress la fournit.
- Aucun changement de tables, métas, routes métier, tombstones, historique ou formule CPL.

---

## 1.9.0 — 2026-08-24

- Corrige définitivement le lien WordPress `Toutes` noir sur noir : `.subsubsub` est stylé directement car WordPress le rend hors de `#posts-filter`.
- Ajoute les réglages par campagne **Enregistrer les appels**, **Dialer côté client** et **Fuseau horaire**.
- Le fuseau proposé provient uniquement de la fiche CRM/WHMCS; aucune recherche d’adresse externe n’est lancée.
- Les appels entrants peuvent demander un enregistrement Twilio conditionnel avec callback Core; les métadonnées d’enregistrement sont synchronisées dans l’historique canonique.
- Les appels sortants restent visibles mais strictement exclus des leads et du CPL.
- La migration réutilise le réglage historique `record_call` pour initialiser le nouveau réglage sans rupture.

## 1.8.1 — 2026-08-24

- Corrige le listing WordPress des campagnes pour qu’il hérite entièrement des couleurs du shell AWM en clair/sombre.
- Rétablit le contraste de « Toutes », filtres, pagination, champs de recherche, tableaux et actions lorsque le thème sombre est changé dynamiquement.
- Remplace les fonds noirs opaques du listing par les surfaces partagées Hub/Core sans modifier les campagnes ni leur historique.

## 1.8.0 — 2026-08-24

- Ajoute le routage entrant par campagne avec **Message 1 — Avertissement** puis **Message 2 — Publicité** avant la redirection.
- Intègre le MP3 d’avertissement Alliance par défaut; Alliance peut le remplacer ou revenir au fichier par défaut.
- Permet au client de téléverser/remplacer/supprimer son Message 2 MP3, de l’activer/désactiver et de modifier son numéro de réception uniquement pour ses campagnes.
- Ajoute le contrôle administratif complet des deux messages et de la destination depuis la fiche client Hub AWM.
- Stocke les MP3 dans un répertoire privé Alliance, limite à 5 Mo, valide la signature MP3 et les sert par une URL Core signée.
- Écrit maintenant les nouveaux appels Twilio entrants et sortants dans `callink_calls` en plus du post type historique; les callbacks mettent à jour statut et durée de façon idempotente.
- Les appels sortants apparaissent dans l’historique comme **Sortant** mais restent strictement exclus des leads et du CPL.
- Conserve la migration Laravel, les identifiants historiques, les exclusions anti-réimportation et les routes existantes.

---

# Changelog — CallTracker AWM

## 1.7.0 — 2026-08-19

- Rafraîchit le lot de migration à partir de l’export Laravel du 19 août 2026.
- Intègre 69 306 appels et 44 712 formulaires attribuables; conserve 17 appels et 2 379 formulaires orphelins hors attribution.
- Utilise le propriétaire canonique de la campagne comme frontière client pour 25 351 appels dont le `client_id` Laravel historique diffère, tout en conservant cet identifiant pour audit.
- Étend l’outil Migration existant aux 3 602 lignes de coûts/CPL et protège les lignes WordPress manuelles.
- Signale les erreurs SQL CPL comme résultat partiel plutôt que comme réussite complète.
- Refuse l’import CPL vers une campagne non publiée, en corbeille, supprimée ou exclue.
- Ajoute le formulaire AWM intégrable par campagne avec défi HMAC, anti-robot, limitation et dédoublonnage.
- Ajoute la réception Connector pour Elementor et autres intégrations locales autorisées.
- Étend `callink_forms` de manière additive aux identifiants de soumission, sources, téléphone, page et empreintes techniques.
- Aligne le nombre de leads sur appels entrants plus formulaires dans l’administration et le portail client.
- Conserve le flux courriel historique comme repli et ne prend pas en charge les fichiers dans cette première version.
- Exige Core AWM 4.5.8; aucune table, route, option, méta ou identité historique n’est supprimée ou renommée.

---

## Historique des versions précédentes

# Changelog — CallTracker AWM

## 1.6.0 — 2026-08-19

### Ajouté
- Service `CallLink_Campaign_Bulk_Actions` pour les aperçus et exécutions groupées de campagnes et réservations locales.
- Actions campagne : archivage, corbeille, libération Twilio, suppression définitive et réattribution cliente.
- Actions inventaire : réservation locale, réattribution et retrait de réservation.
- Aperçu serveur détaillé, phrase de confirmation, jeton à usage unique revendiqué atomiquement, empreinte d’état, verrouillage concurrent, limites de lot et résultats par élément.
- API interne d’inventaire partagée par les parcours unitaires et groupés : normalisation, lecture, écriture et retrait de réservation.

### Sécurité et compatibilité
- Niveau Core `calltracker/approve`, nonce, validation stricte, confirmation sensible à la casse et journalisation pour chaque lot sensible.
- Le client cible d’une réservation est revalidé côté serveur avec la même éligibilité CallTracker que l’interface.
- Inventaire Twilio relu directement lors de l’exécution d’un lot de réservations.
- Exclusion legacy explicitement persistée pour les mises à la corbeille et suppressions personnalisées.
- Appels et formulaires conservés; aucune table, option, route, méta ou identifiant historique renommé ou supprimé.
- Le post type historique `callink_campaign` et le statut technique `publish` restent compatibles et non publics.

### Corrigé
- Les suppressions par changement direct de statut ne peuvent plus contourner la protection anti-réimportation.
- Les actions unitaires et groupées utilisent maintenant la même frontière de validation des réservations.
- Une erreur de nettoyage local après une libération Twilio irréversible est signalée et journalisée sans présenter la libération externe comme annulée.
- La libération Twilio retire désormais la réservation locale depuis une seule frontière partagée par les parcours unitaires et groupés.
- Les lots campagne qui libèrent ou réattribuent un numéro verrouillent aussi la ressource téléphonique afin d’éviter une collision avec un lot de réservations.
- Les corbeilles et suppressions destructives échouent de manière fermée si l’exclusion legacy d’une campagne historique ne peut pas être réellement persistée.
- Les options partagées de réservations, d’exclusions legacy et d’instantanés de suppression utilisent maintenant des écritures sérialisées avec relecture de persistance.
- Après une libération Twilio acceptée, l’état local, les appels entrants, le Dialer et le retrait de réservation sont contrôlés séparément; toute divergence est signalée dans le résultat et le journal Core.
- Une réattribution vérifie le propriétaire enregistré, restaure la réservation concurrente si l’écriture principale échoue et compare le nombre d’appels/formulaires réellement propagés.

---

## 1.5.1 — 2026-08-19
- L’éditeur natif `callink_campaign` n’utilise plus le workflow éditorial WordPress : libellés Campagne, boîte Publier retirée et colonne latérale de publication supprimée.
- Ajout d’une barre AWM « Enregistrer la campagne »; le statut WordPress `publish` reste uniquement un état technique interne de compatibilité.
- Les messages « Article mis à jour » deviennent « Campagne enregistrée » et sont consommés par le loader AWM au lieu d’un bandeau.
- La liste Campagnes masque les vues de statuts éditoriaux WordPress et remplace la colonne Publication par « Dernière modification ».
- La campagne reste explicitement non publique et non exposée au front-end.

## 1.5.0 — 2026-08-19
- Ajout de l’inventaire Twilio à quatre états : **Libre, Réservé, Attribué, À vérifier**.
- Comparaison serveur du compte Twilio Alliance avec toutes les campagnes CallTracker sans exposer les identifiants Twilio au navigateur.
- Détection des doublons de numéro, campagnes locales absentes du compte Twilio, réservations orphelines et numéros encore détenus après corbeille/libération déclarée.
- Affichage du dernier rattachement connu, de la campagne et du client lorsque disponibles.
- Réservation et retrait de réservation protégés par permission CallTracker Modifier, nonce, validation et journal de sécurité Core.
- Cache Twilio court et invalidation automatique après achat ou libération d’un numéro.

## 1.4.1 — 2026-08-18
- Le Dialer accepte maintenant une campagne liée à un alias historique sûr du client canonique, via le résolveur d’identité Core 4.5.4.
- Les contrôles restent stricts : campagne publiée, statut actif, Dialer activé, numéro Twilio présent et identité cliente reliée de façon sûre.
- Les nouveaux appels sortants lancés depuis le Hub Client sont attribués à la fiche canonique portée par la session lorsque la campagne conserve encore un ancien propriétaire technique.

## 1.4.0 — 2026-08-18

- CallTracker AWM 1.4.0 devient la référence officielle du shell visuel AWM partagé. Son ancien en-tête spécifique est remplacé par le shell Core afin d’éviter les doublons tout en conservant toutes les routes et fonctions existantes.


## Sécurité 1.3.7 — 2026-08-17

- CallTracker AWM 1.3.7 utilise le coffre Core 4.4.0 pour protéger au repos les secrets Twilio et Google Ads sans modifier les routes historiques.
# Changelog — CallTracker AWM

## 1.3.6 — 2026-08-17
- Les routes REST historiques Twilio `/callink/v1/token`, `/voice`, `/incoming` et `/status` sont désormais enregistrées exclusivement par Core AWM 4.3.9.
- CallTracker conserve le traitement métier Twilio mais n’est plus propriétaire de la surface API publique.
- Les URL historiques restent strictement inchangées.


## 1.3.5 — 2026-08-17
- Les campagnes historiques mises à la corbeille ou supprimées définitivement sont maintenant inscrites dans une liste d’exclusion persistante (`callink_legacy_campaign_tombstones`).
- Les synchronisations/migrations depuis l’ancienne plateforme ignorent systématiquement ces campagnes et ne peuvent plus les republier ni les recréer automatiquement.
- Une campagne déjà présente dans la corbeille au moment d’une synchronisation est automatiquement protégée contre la résurrection.
- Une restauration WordPress explicite retire l’exclusion et autorise de nouveau la synchronisation de cette campagne.
- Les exclusions et restaurations sont consignées dans le journal de sécurité Core lorsqu’il est disponible.

## 1.3.4 — 2026-08-17
- Correctif global des associations historiques Clients ↔ Campagnes : les campagnes liées à une ancienne adresse du même client sont maintenant visibles dans la fiche CallTracker canonique lorsqu’une correspondance sûre peut être établie.
- Exemple couvert : une campagne liée à `info@domaine.tld` et une fiche WHMCS liée à `proprietaire@domaine.tld`, avec identité cohérente.
- Aucun rattachement n’est réécrit silencieusement; les consolidations permanentes restent soumises au rapprochement global contrôlé.


## 1.3.3 — 2026-08-17
- Rapprochement global de l’ensemble des anciennes fiches CallTracker vers les fiches WHMCS canoniques, avec fusion en lot limitée aux correspondances sûres et uniques.
- Les campagnes, appels et formulaires suivent la fiche canonique après rapprochement; les cas ambigus restent visibles pour validation manuelle.
- Correction du rendu réel des écrans WordPress de campagnes : retrait du logo historique dupliqué et conservation d’un seul en-tête CallTracker en haut.
- Harmonisation complète du listing et de l’éditeur Campagnes en clair/sombre, incluant champs, metaboxes, publication, tableaux et actions.
- Compatibilité des associations clients historiques : les campagnes liées par ID WHMCS ou courriel sûr apparaissent dans la fiche CRM/WHMCS canonique.
- Agrégation des compteurs de campagnes, appels et formulaires sur les références sûres du même client.

## 1.3.2 — 2026-08-17
- Amélioration du parcours Campagnes : visualisation consolidée des appels et formulaires par campagne.
- Campagnes associées visibles depuis la fiche client avec compteurs et accès direct à l’activité.
- Harmonisation visuelle de l’administration Campagnes et en-tête CallTracker avec le thème AWM.


## 1.3.1 — 2026-08-17

- Activation ou désactivation d’un client pour CallTracker sans modifier son statut WHMCS/CRM.
- Les clients CallTracker actifs sont les seuls proposés lors de la création d’une campagne avec achat Twilio.
- Rattachement direct d’une campagne existante non assignée depuis l’écran Clients.
- Préselection du client lors de l’ouverture de « Nouvelle campagne ».
- Refus serveur d’un achat ou d’un jeton Dialer client lorsque CallTracker est désactivé pour ce client.
- Compatibilité préservée pour les clients ayant déjà des campagnes historiques.


## 1.3.0 — 2026-08-17

- Ajout d’un accès Clients directement dans CallTracker AWM.
- Recherche des clients par nom, entreprise, courriel, téléphone, campagne ou numéro Twilio.
- Filtres Actifs, Inactifs et Tous disponibles depuis CallTracker; les clients inactifs restent masqués par défaut.
- La référence WHMCS demeure la source du statut actif, avec respect des exceptions manuelles et de la fiche interne Alliance Web Marketing.
- Réutilisation de la route historique `callink-clients` et des métadonnées existantes, sans nouvelle table ni duplication de clients.

# Historique — CallTracker AWM

## 1.2.0 — 2026-08-17

- Contrat de permissions Core AWM 1.0 appliqué aux campagnes, numéros, historique et CPL.
- Niveaux distincts pour consultation, opérations quotidiennes, approbation et réglages.
- Signatures Twilio refusées consignées dans le journal central avec limitation anti-bruit.
- Diagnostic Core des webhooks Twilio et du Dialer.
- Activation arrêtée proprement avec Core antérieur à 4.3.0, sans modification des campagnes ni de l’historique.

## 1.1.2 — 2026-08-15

- Libération explicite d’un numéro Twilio sans recopie manuelle.
- Comparaison serveur du numéro enregistré avant l’appel irréversible à Twilio.

---

## README.md

## LeadTracker AWM 1.11.76 - Destinations dynamiques
Le câblage affiche maintenant uniquement les destinations réellement utilisées par la campagne. Capturia n est plus présenté comme une configuration manquante chez tous les clients. Le libellé générique **CRM externes** prépare l ajout futur d autres fournisseurs sans modifier le modèle de campagne.

## 2026-10-20 - LeadTracker AWM 1.11.75
Le moteur Capturia central conserve l envoi immediat valide terrain. Identity Mapping v2 normalise nom/prenom avant `POST /contacts` et empeche qu un email, telephone ou URL soit transmis comme identite humaine. Le tag Google, les notes, la preuve PII-free et l idempotence restent inchanges.

## 2026-10-19 - LeadTracker AWM 1.11.74 - packaging runtime minimal

Le paquet installé contient uniquement le runtime courant et la documentation active : `README.md`, `CHANGELOG.md`, `ROADMAP.md`, `RELEASE-NOTES-1.11.74.md` et `VALIDATION-LEADTRACKER-AWM-1.11.74.md`. Les documents unitaires des anciennes versions sont conservés dans l'archive/dépôt central, pas sur le WordPress de production. Le dossier `data/history` reste inclus car il est consommé par le moteur de migration historique et ne représente pas d'anciennes versions du code.

## 2026-10-19 - LeadTracker AWM 1.11.73 - correctif packaging securise

- Aucun changement fonctionnel par rapport a 1.11.72 : la vue Leads unifiee appels + formulaires et la fiche detaillee au clic sont conservees.
- Le paquet 1.11.72 contenait par erreur deux copies byte-for-byte identiques du module (`calltracker_new/` et `awm-calltracker/`), ce qui portait la taille extraite a environ 381 Mo et declenchait la limite Core de 256 Mo par module.
- Le paquet 1.11.73 ne contient qu une seule racine livrable `awm-calltracker/`; les arbres de travail sont exclus.
- La limite Core n est pas relevee ni contournee : le packaging est corrige a la source.

## 2026-10-19 - LeadTracker AWM 1.11.72 - leads unifies appels + formulaires et fiche detaillee

- La section « Leads de la campagne » additionne maintenant les appels entrants et les formulaires, selon la meme definition que le CPL : appels entrants + formulaires.
- Les compteurs affichent Leads totaux, Appels, Formulaires, puis le detail des moteurs de formulaires.
- Les 20 derniers leads sont fusionnes dans une seule chronologie, avec badge Appel/Formulaire et heure Toronto.
- Un clic sur n importe quel lead ouvre sa fiche detaillee sans quitter la campagne.
- Formulaire : nom, courriel, telephone, formulaire, source, page, statut, message, sujet, reponses completes du payload et references utiles; secrets/token/captcha/API restent filtres.
- Appel : appelant, numero suivi, statut, duree, localisation, Call SID, Child SID, enregistrement protege quand disponible et etapes de routage.
- Les appels ne sont jamais presentes comme des preuves Capturia; Capturia reste applicable aux formulaires VMV-NAT seulement.

## 2026-10-19 - LeadTracker AWM 1.11.71 - liaison Google Ads persistante et historique CPL automatique

- Une association Google Ads devient une configuration persistante : MCC, compte client, mode compte/campagnes et sélection de campagnes sont mémorisés avec une empreinte stable et un historique de liaison.
- Toute modification de cette association déclenche automatiquement un worker de récupération de tout l historique Google Ads disponible, du premier mois réellement observé jusqu au mois courant, sans limiter le recalcul au mois courant/précédent.
- Chaque mois est réconcilié avec le barème AWM officiel 50/40/30/20/15; le rabais continue de s appliquer sur les frais de gestion, jamais sur l investissement.
- Les lignes CPL plus anciennes que la fenêtre vérifiable Google Ads ne sont jamais supprimées ni écrasées.
- Chaque mois conserve désormais des instantanés de résultat Google Ads/CPL : investissement, frais, rabais, coûts annexes, appels, formulaires, leads, coût total et CPL calculé. Le premier résultat reste conservé et les vérifications ultérieures sont auditées.
- Le worker est idempotent par empreinte de configuration et conserve son état (en attente, en cours, complet, partiel ou erreur) pour diagnostic.
- Hub AWM 4.5.90 complète ce contrat en empêchant un enregistrement partiel de vider silencieusement un compte Google Ads déjà associé et en affichant l état de l historique directement dans la campagne.

## 2026-10-18 - LeadTracker AWM 1.11.70 - campagne active = synchronisation automatique

- Nouvelle règle opérationnelle : une campagne publiée dont le statut LeadTracker est `active` doit maintenir automatiquement ses entrées configurées sans clic sur « Synchroniser ».
- Numéro Twilio : à l’activation ou après une modification de campagne, LeadTracker applique le routage entrant puis relit Twilio pour vérifier que le VoiceUrl AWM est réellement actif. Les erreurs restent visibles dans `_callink_twilio_sync_error`; aucune réussite n’est inventée.
- Formulaires : pour toute campagne active ayant des associations/form capture configurées, LeadTracker rafraîchit les inventaires Hub Client, rapproche les formulaires déjà reçus et réapplique les mappings enregistrés. Aucun formulaire non rattaché n’est deviné automatiquement, sauf la règle spéciale VMV-NAT `capturia_auto_all_forms` déjà existante.
- Un worker de convergence traite les changements immédiatement en arrière-plan et recontrôle ensuite les campagnes actives par petits lots. Le numéro est revalidé périodiquement et les formulaires sont rafraîchis sans dépendre d’un opérateur.
- Les changements de statut, numéro, destination, client, mappings ou activation de capture déclenchent automatiquement la convergence de la campagne.
- Le bouton manuel « Synchroniser les formulaires » reste disponible uniquement pour forcer un diagnostic/scan immédiat.
- Hub Client 1.14.33 complète ce contrat : mappings actifs actualisés en arrière-plan et lecture fraîche obligatoire juste avant chaque vraie soumission Elementor, Gravity Forms, Contact Form 7 ou hook AWM.

## 2026-10-18 - LeadTracker AWM 1.11.69 - moteur Capturia central temps réel

- Les nouveaux leads VMV-NAT sont maintenant envoyés à Capturia directement par LeadTracker, dans la même requête que `forms/submit`, via le moteur central déjà utilisé pour la reprise des 563 formulaires historiques.
- Le lead exact est mis en file idempotente par `campaign_post_id + form_row_id`; aucun ancien lead n'est rejoué automatiquement.
- Le chemin normal ne dépend plus d'un second appel mutatif depuis Hub Client : Hub Client reçoit `central_owned=1` et n'a pas le droit de créer un deuxième contact.
- Une preuve centrale est écrite avant l'appel API puis enrichie à chaque étape : Contact, Google, Données, contact_id, request-id, HTTP et heure Toronto.
- En cas de 429, seul le lead exact est replanifié. Une réponse réseau/mutative incertaine reste arrêtée sans rejeu aveugle.
- En mode confidentialité CRM Client AWM, LeadTracker crée et tague le contact puis Hub Client 1.14.32 ajoute uniquement les réponses complètes depuis le miroir local chiffré au même contact et met à jour la même preuve.

## 2026-10-16 - LeadTracker AWM 1.11.68 - preuve Capturia renforcée par lead

- La colonne Capturia affiche maintenant, quand disponibles, l'identifiant du contact Capturia, l'identifiant de requête API, le code HTTP et l'heure de livraison en plus de `Contact ✓ · Google ✓ · Données ✓`.
- Le tableau « Preuve des nouveaux formulaires » expose aussi le request ID et HTTP afin de fournir une preuve technique exploitable sans accès au tableau de bord Capturia.
- `delivery_for_form_ids()` transporte maintenant `request_id` jusqu'à la ligne exacte du lead.
- Aucun envoi supplémentaire n'est généré par l'affichage : la preuve provient uniquement du reçu authentifié envoyé par Hub Client après la vraie tentative Capturia.

## 2026-10-16 - LeadTracker AWM 1.11.67 - accès direct à la campagne déjà ouverte

- Corrige l export CSV de campagne afin d inclure les leads déjà envoyés ou déjà présents dans Capturia, au lieu de les exclure.
- L export fusionne les soumissions LeadTracker et les archives Capturia de la campagne, en privilégiant la ligne formulaire comme source principale.
- Déduplication conservatrice : lien technique contact/formulaire quand disponible; sinon même courriel ou téléphone normalisé dans une fenêtre maximale de 24 h, en un-à-un.
- Un lead présent uniquement dans Capturia reste dans le CSV avec la provenance `Archive Capturia uniquement`; il n est pas perdu.
- Nouvelles colonnes client : Présent dans Capturia, Statut Capturia, ID contact Capturia et Provenance export.
- Les filtres Du/Au et le choix des formulaires rattachés sont conservés. Un contact Capturia lié à un formulaire décoché ne peut pas être réintroduit par l archive.
- `capturia_unassigned` reste exclu car il n appartient pas encore à la campagne VMV-NAT.
- Export strictement en lecture seule : aucun courriel, aucun appel API Capturia et aucune mutation de lead.

## 2026-10-16 - LeadTracker AWM 1.11.65 - export CSV par campagne

- Nouvelle section **Export CSV des formulaires** directement sous la liste des leads d'une campagne.
- Choix de la période (Du/Au) et des formulaires rattachés, tous présélectionnés par défaut.
- Export client lisible: identité, téléphone, formulaire, page d'origine, message et champs de formulaire, sans secrets techniques ni contacts importés de Capturia.
- CSV UTF-8/Excel FR-CA, protection anti-injection et limite de sécurité de 25 000 lignes.
- Aucun envoi, courriel ou mutation n'est déclenché par l'export.

## 2026-10-16 - LeadTracker AWM 1.11.64 - ordre d'envoi Capturia autoritaire dans forms/submit

- Corrige le cas terrain où LeadTracker recevait immédiatement le formulaire VMV-NAT mais Hub Client n'obtenait aucune preuve Capturia.
- La réponse authentifiée `forms/submit` transporte maintenant une instruction PII-free `capturia_dispatch` calculée sur Alliance pour la campagne exacte qui vient d'être enregistrée.
- Cause racine terrain supplémentaire corrigée : `connector_vmv_credential()` exigeait encore au moins un mapping formulaire individuel alors que VMV-NAT est maintenant en mode `capturia_auto_all_forms`. Cette ancienne garde pouvait accepter le lead dans LeadTracker puis refuser silencieusement la credential Capturia. La route auto-all-forms n exige plus de mapping individuel sur le WordPress principal VMV.
- Hub Client n'a plus besoin de redécouvrir l'intention Capturia via une seconde lecture de `forms/campaigns` avant l'envoi; un cache, une synchronisation de mappings ou une lecture transitoire ne peut donc plus annuler silencieusement la livraison.
- L'instruction ne contient jamais la clé API. Elle indique uniquement demandé/autorisé, campagne, mode tous formulaires et, en cas de blocage, un code/message technique.
- Si la route centrale est invalide, le prochain Hub Client peut enregistrer une preuve `Bloqué` avec la raison exacte au lieu de laisser le lead en `Sans preuve`.
- Corrige aussi le repli des anciennes clés par campagne : si VMV-NAT ne porte pas elle-même le secret mais qu une seule connexion Capturia du même client existe, le Connector réutilise cette source autorisée au lieu de retourner `clé illisible`.

## 2026-10-15 - LeadTracker AWM 1.11.63 - Capturia automatique pour tous les formulaires VMV-NAT

- Le contrat Connector annonce `capturia_auto_all_forms` pour VMV-NAT lorsque la destination Capturia est active.
- Le câblage n exige plus de sélectionner manuellement chaque formulaire VMV-NAT : Hub Client capture automatiquement les formulaires du site principal, tout en respectant une association explicite à une autre campagne.
- Activer Capturia maintient la réception LeadTracker active pour la campagne; désactiver Capturia redevient un choix explicite.
- Les preuves restent rattachées au lead exact et affichées en America/Toronto.

## 2026-10-15 - LeadTracker AWM 1.11.62 - preuve Capturia par lead et heure Toronto

- Corrige l affichage des heures VMV-NAT : les horodatages techniques restent en UTC mais la page Cablage des leads les affiche maintenant via l horloge Core America/Toronto avec HAE/HNE automatique.
- La liste des leads VMV-NAT ajoute une colonne Capturia par formulaire : Confirme, En attente, Bloque, A confirmer ou Aucune preuve technique recue.
- La preuve expose les etapes techniques Contact / Google / Donnees afin de distinguer creation du contact, etiquette et notes sans ouvrir Capturia.
- Le recu technique accepte source, identifiant de formulaire, phase et curseur de notes; il reste strictement sans nom, courriel, telephone ni contenu de formulaire.
- Le connecteur accepte un submitted_at_utc explicite. Une resoumission idempotente recente peut reconciler l heure UTC et completer nom/courriel/telephone manquants sans creer un doublon.
- Le cablage Capturia VMV-NAT accepte maintenant tout formulaire explicitement associe sur le site principal parmi Elementor, Gravity Forms et Contact Form 7; le moteur du formulaire ne peut plus etre un motif de rejet silencieux.
- Aucun historique 563 n est relance par cette version.

## 2026-10-15 - LeadTracker AWM 1.11.61 - vrai contact Elementor et séparation CRM / preuve

- Les nouveaux formulaires Hub Client utilisent le vrai **nom, courriel et téléphone** lorsque ces données existent; `Demande Web` devient le dernier recours uniquement si aucune identité exploitable n est disponible.
- Les libellés Elementor français/anglais courants sont reconnus : nom complet, prénom/nom, courriel/email, téléphone/cellulaire/mobile et variantes proches.
- En mode `local_mirror_v1`, LeadTracker conserve seulement l identité opérationnelle minimale nécessaire à l affichage et à la déduplication; les réponses complètes restent dans le miroir local chiffré et sont envoyées au CRM Capturia pour VMV-NAT.
- La table de preuve Capturia demeure sans PII et continue d afficher uniquement le statut de livraison, les identifiants techniques et les horodatages.
- Les journaux ajoutent seulement des indicateurs booléens `identity_*_present`; aucune valeur nominative n est écrite dans le journal de sécurité.
- La récupération de tous les contacts Capturia manquants de 1.11.60 est conservée sans changement.

## 2026-10-15 - LeadTracker AWM 1.11.60 - Capturia : preuve des nouveaux envois et récupération des archives manquantes

- Ajoute dans **Câblage des leads > VMV-NAT** une preuve technique des nouveaux formulaires envoyés vers Capturia : statut, identifiant de ligne AWM, identifiant contact Capturia et horodatage, sans stocker de nouvelle copie nominative dans la table de preuves.
- Ajoute **Récupérer tous les leads Capturia manquants** : AWM parcourt tous les contacts lisibles par la clé API Core de Vendre Maison Vite, compare les identifiants Capturia et les formulaires déjà connus, puis importe uniquement les contacts absents de l archive courante.
- Les contacts déjà issus des 563 formulaires historiques acceptés ou des nouveaux formulaires AWM sont reliés à leur ligne existante plutôt que dupliqués.
- Une attribution de campagne ambiguë n est jamais forcée : le contact est conservé comme **Capturia - à classer** au niveau du client et reste hors CPL jusqu à qualification.
- Le scan respecte les pauses HTTP 429 et reprend par WP-Cron / AJAX. Aucun scan ni nouvel envoi n est lancé à l installation.
- VMV-NAT reste une campagne SEO pour le CPL; `Google` reste uniquement la destination Capturia.

## 2026-10-15 - LeadTracker AWM 1.11.59 - Capturia : reprise adaptive apres HTTP 429

- La reprise historique VMV-NAT n envoie plus plusieurs formulaires simultanement : un seul formulaire est traite par passage, avec espacement des requetes d ecriture.
- Capturia HTTP 429 n est plus traite comme une erreur fatale : LeadTracker lit `Retry-After` / `RateLimit-Reset` quand disponible, applique une pause globale, puis reprend automatiquement.
- Le navigateur et WP-Cron partagent un verrou de traitement afin d eviter deux workers Capturia concurrents sur la meme campagne.
- Les lignes deja acceptees restent acquises; les lignes en attente/retry conservent leurs cles d idempotence. Aucun formulaire n est reinitialise par la mise a jour.
- Pendant un backfill actif, le bouton de verification Capturia ne lance plus de nouvelles requetes inutiles : il affiche l etat du transfert et la pause eventuelle.
- Aucun envoi Capturia n est declenche a l installation. VMV-NAT reste SEO pour le CPL et Capturia reste reserve a Vendre Maison Vite.

## 2026-10-15 - LeadTracker AWM 1.11.58 - Cablage Capturia lit correctement la cle Core

- Corrige le faux message « La cle API Capturia est absente ou illisible » dans **Cablage des leads > VMV-NAT** alors que la meme cle est validee dans Core AWM et dans la fiche campagne.
- Cause : une connexion Capturia geree par Core n appartient volontairement a aucune campagne (`campaign_id=0`). Le bouton de verification transmettait ce `0` au moteur Capturia, qui ne pouvait alors pas retrouver le client Vendre Maison Vite ni la cle Core.
- Correction : la verification utilise VMV-NAT comme contexte de campagne lorsque la credential vient de Core; le chemin historique conserve son identifiant de campagne d origine.
- L interface indique maintenant explicitement « Cle Capturia geree dans Core AWM pour Vendre Maison Vite » au lieu de « campagne #0 ».
- Aucun changement de cle, aucun envoi Capturia et aucun backfill ne sont executes a l installation. La reprise historique 564 formulaires de 1.11.57 reste manuelle et idempotente.


## 2026-10-15 - LeadTracker AWM 1.11.57 - VMV-NAT : reprise des 564 formulaires vers Capturia Google

- Ajoute une reprise historique manuelle et idempotente pour **VMV-NAT uniquement** : les formulaires deja rattaches a la campagne sont figes dans un instantane puis envoyes par lots vers Capturia avec l etiquette normale **Google**.
- Le traitement conserve un etat technique par formulaire (sans PII), reprend apres interruption et stoppe les resultats reseau incertains au lieu de rejouer aveuglement une creation.
- Les formulaires dont la source est deja `capturia` ne sont jamais renvoyes. Un formulaire sans courriel ni telephone reste bloque et visible dans le bilan.
- Avant le premier envoi, LeadTracker exige une confirmation explicite que l import historique ne declenchera pas une sequence SMS/courriel indesirable dans Capturia.
- Le statut commercial CRM **Actif/Inactif** est desormais independant des campagnes et des leads : `Inactif` ne bloque plus l activation de campagne, Capturia ou la collecte. Un dossier archive/supprime ou un rattachement non canonique reste bloque.
- La campagne reste classee **SEO** pour le CPL. La destination Capturia `Google` ne transforme pas VMV-NAT en campagne Google Ads.
- Aucun envoi n est lance a l installation : l operateur doit ouvrir Cablage des leads > VMV-NAT et confirmer la reprise.

## 2026-10-15 - LeadTracker AWM 1.11.56 - Capturia gere dans Core

- LeadTracker ne propose plus de champ pour enregistrer/remplacer la cle Capturia. Le bouton ouvre `Core AWM > Connexions > Coffre et cles`.
- Pour les campagnes du client CRM **Vendre Maison Vite**, la cle centralisee Core est lue en priorite en memoire serveur.
- Les anciennes cles chiffrees par campagne restent lisibles temporairement comme repli, sans nouvelle ecriture dans LeadTracker.
- Un remplacement de cle dans Core invalide uniquement les caches de capacites/compte/sources; aucun lead historique ni mapping CPL n est purge.
- La planification Capturia reconnait aussi une campagne active utilisant la cle Core meme si aucun ancien meta de cle n existe.
- Capturia n est pas active pour les autres clients.

## 2026-10-14 - 1.11.55 / Suite AWM 4.5.404 - CRM Clients

Nouvelle vue CRM Clients - resultats, en lecture directe sans cache nominatif. Les lecteurs et collecteurs historiques restent disponibles.

Candidate de migration additive : tests locaux, essai WordPress/MySQL et sites clients requis.
Aucun transfert a l'installation. Ne supprime ni sources historiques, ni audio Twilio.
Un seul lancement global depuis CRM AWM > CRM Clients - campagnes et leads.
Prealables : trousseau Core enrole et sauvegarde separement; Hub Client 1.14.22 sur sources et destination; autorisations techniques.
Le statut commercial et le statut des campagnes ne sont pas modifies. Capturia n'est jamais exige ni active pour les autres clients.

---

## LeadTracker AWM 1.11.54 — Statut client CRM canonique à l'activation de campagne (13 octobre 2026)
- La garde d'activation respecte le statut CRM du véritable dossier client `callink_client`; un CRM Actif n'est plus bloqué par `_callink_status=disabled` ou `_callink_manual_inactive=1` hérités.
- Client absent, supprimé, avec mauvais rôle ou non canonique : activation refusée avec identifiant et message de rattachement; CRM Inactif/Archivé et campagnes brouillon/archivées restent refusés.
- Aucun rapprochement ni mutation automatique du `client_id` historique; si le lien de campagne pointe vers un autre dossier, la réconciliation doit être vérifiée séparément.
- Aucun recalcul CPL, aucune réattribution de lead, et aucun envoi Capturia dans cette version.

## LeadTracker 1.11.53 — Bouton de campagne et Capturia seulement sur les campagnes concernées
- Le statut en haut de la fiche campagne et dans Câblage devient cliquable avec confirmation et retour serveur, sans lier l'activation au nombre de formulaires.
- Le voyant Capturia et son panneau spécialisé sont masqués pour les campagnes ordinaires sans intégration configurée; VMV-NAT conserve son parcours préparatoire.
- L'action reste soumise aux contrôles de permission, aux statuts CRM et à un enregistrement vérifié. Aucun changement de campagne à l'installation. Terrain à confirmer.

## LeadTracker 1.11.52 — statuts de connexion explicites
- Trois indicateurs indépendants dans l’éditeur de campagne et dans « Câblage des leads » : session WordPress Alliance, état métier `_callink_status`, Capturia lecture/écriture/validation.
- « Connexion active » n’est plus affiché comme preuve que la campagne reçoit des leads. Les campagnes en pause restent en pause, aucun lead ni CPL modifié.
- Les permissions Capturia absentes sont présentées comme « inconnues » et non comme lecture seule certaine. Une vérification en lecture ne valide jamais un envoi réel; messages d’avertissement cohérents.
- Libellés et pastilles accessibles, responsives et adaptés aux modes clair/sombre. Validation terrain et publication effective de la roadmap publique en attente.

# Source existante Capturia — VMV-NAT

La clé déjà chiffrée dans Core est réutilisée pour le même client CRM, aucun nouveau champ API. La fiche `Câblage des leads` commande l'activation d'envoi des **nouveaux** formulaires Elementor VMV-NAT (SEO) du site principal vers l'étiquette **Google** ; le sous-domaine Google Ads et son historique ne sont pas touchés. Nécessite Hub Client 1.14.21 et Core 4.5.283 sur le site VMV appairé. L'API Capturia doit confirmer `contacts:write`, `tags:read` et une étiquette normale existante « Google » avant envoi. Voir guide suite.

# LeadTracker AWM 1.11.51 — interface de configuration directe

Depuis **LeadTracker → Câblage des leads → VMV-NAT → Gérer dans LeadTracker**, administrer les formulaires associés au site, afficher les leads et récupérer des soumissions non attribuées déjà présentes dans l'historique LeadTracker. Pour une campagne en pause, choisir explicitement de l'activer seulement après avoir vérifié les autres entrées liées à la même campagne.

La destination **Capturia · Google** est déclarative et ne transmet pas encore les formulaires. La clé saisie est sauvegardée chiffrée dans Core; « Vérifier » est une lecture seule. Aucune écriture Capturia, aucun SMS, aucun transfert de leads n'est déclenché avec cette version. Les leads absents du Hub mais encore présents uniquement chez Elementor ne peuvent pas être récupérés sans un connecteur d'import supplémentaire.

# LeadTracker AWM 1.11.50

## Règles CPL par source
- **Google Ads** : dépenses API + barème AWM 50/40/30/20/15 %.
- **SEO** : dépense mensuelle fixe, **aucun frais de gestion**.
- **Autre** : dépense mensuelle fixe, avec frais de gestion facultatifs : aucun, pourcentage ou montant fixe mensuel.

L harmonisation applique ces règles à tous les mois depuis la date choisie sans modifier les coûts annexes déjà enregistrés.

# LeadTracker AWM 1.11.49

## CPL multi-source
Chaque campagne peut être classée **Google Ads**, **SEO** ou **Autre**. Google Ads utilise l API; SEO/Autre utilisent une dépense mensuelle fixe harmonisable sur tous les mois depuis une date choisie. Le Centre CPL applique ensuite le même moteur de leads et le barème AWM sur l historique.

## 1.11.48 — récupération réellement automatique
La récupération historique ne demande plus à Google Ads les champs de date de début/fin de campagne qui ont été refusés sur le terrain. LeadTracker parcourt directement l historique mensuel disponible, trouve le premier mois réellement retourné par Google Ads, puis corrige tous les mois jusqu au présent. Les mois antérieurs sans preuve Google Ads restent intacts.

# LeadTracker AWM 1.11.48

## Historique Google Ads résilient
Le moteur historique découpe maintenant la récupération Google Ads en tranches annuelles invisibles pour l utilisateur. Si une tranche est refusée, le moteur retente automatiquement les mois de cette tranche, conserve la continuité de l historique et remonte le vrai détail Google Ads. Le parcours utilisateur reste une seule action.


## Synchronisation globale Google Ads → CPL
Une seule action peut maintenant parcourir toutes les campagnes LeadTracker câblées à Google Ads, récupérer automatiquement tout l historique mensuel disponible pour chaque CPL, corriger les investissements mois par mois puis appliquer le barème AWM officiel à l ensemble des lignes CPL. Le rabais reste calculé sur les frais de gestion et les autres coûts ne sont pas modifiés.


## 1.11.45 — récupération automatique de tous les mois Google Ads
L audit historique n utilise plus une plage `segments.date` sur plusieurs années. LeadTracker interroge Google Ads à la granularité `segments.month`, récupère automatiquement tous les mois disponibles en une seule opération et corrige ensuite chaque ligne CPL sans action mois par mois. Les mois plus anciens que la rétention mensuelle Google Ads sont conservés sans écrasement.


Historique CPL peut maintenant lancer un **audit complet Google Ads** : LeadTracker détecte le début des campagnes Google Ads cochées, lit les dépenses agrégées mois par mois jusqu au mois courant, compare avec les montants enregistrés et corrige automatiquement les écarts. Les autres coûts mensuels sont préservés; les investissements sous 100 $ sont corrigés mais le taux de gestion reste À vérifier.

## Google Ads — plusieurs campagnes pour un même CPL
Une campagne LeadTracker peut être reliée à plusieurs campagnes Google Ads du même compte. LeadTracker additionne les dépenses mensuelles des campagnes cochées avant d appliquer la formule CPL. Les anciens câblages à une seule campagne restent compatibles sans migration manuelle.

# LeadTracker AWM 1.11.42

## 1.11.42 — recherche instantanée du câblage
Le tableau **Câblage des leads** ajoute un moteur de recherche instantané pensé pour l’exploitation et les stagiaires. Il recherche sans rechargement dans le nom de campagne, le client, les domaines, les identifiants et types de formulaires, les numéros de téléphone, Capturia, CRM Client AWM et les états à vérifier.

Des filtres **Tous / Fonctionnels / À vérifier**, un compteur de résultats, un état vide guidé, un bouton d’effacement et le raccourci clavier `/` complètent la recherche. La recherche ignore les accents et accepte plusieurs mots dans n’importe quel ordre.


## 1.11.41 — LeadTracker AWM et tableau de câblage des leads
Le nom produit visible devient **LeadTracker AWM**. Les identifiants techniques historiques (`awm-calltracker`, `callink_*`, tables, routes et classes) restent inchangés afin de conserver les campagnes, appels, formulaires, CPL et migrations existants.

Le nouvel écran **Câblage des leads** montre visuellement les entrées (formulaires, numéros, Capturia), la campagne d attribution et les destinations, dont **CRM Client AWM** lorsqu il est appliqué au client. Le transport formulaire accepte aussi le mode `local_mirror_v1`: les données nominatives restent chiffrées chez le client tandis que LeadTracker conserve l attribution, le CPL et des empreintes d identité non réversibles pour la déduplication.


## 1.11.40 — Capturia validé et CPL dédupliqué
Après une synchronisation réussie des sources et des contacts, le diagnostic n’affiche plus « Profil de clé : À analyser » : il passe à **Clé validée** lorsque les lectures `tags:read` et `contacts:read` sont réellement prouvées. La réconciliation du tag reste stockée en UTC, mais son heure est affichée dans le même fuseau WordPress que le reste de l’interface.

Le CPL protège aussi contre le double comptage entre les formulaires AWM et Capturia. Pour chaque mois, CallTracker compare les leads Capturia aux formulaires non Capturia de la même campagne. Un même courriel ou un même téléphone normalisé à moins de 24 h est considéré comme la même conversion, avec appariement un-à-un. La ligne Capturia reste conservée dans l’historique et le pipeline; seule sa contribution au dénominateur CPL est exclue. Le panneau indique le nombre **Doublons AWM exclus**.


## Capturia — consolidation du vrai dossier CRM actif
Une campagne historique peut encore pointer vers un ancien utilisateur WordPress issu de la migration Laravel, même si CRM AWM possède ensuite un nouveau dossier opérationnel pour la même personne ou entreprise. Le simple fait qu'un ancien utilisateur possède `_callink_legacy_user_id` n'en fait donc pas forcément le dossier CRM à utiliser.

Pour les campagnes migrées, CallTracker utilise maintenant l'identité réelle du client legacy (nom, courriel, entreprise et téléphone). Si le dossier directement lié au legacy est inactif mais qu'un **seul dossier CRM actif** correspond fortement à la même identité, Capturia utilise ce dossier actif. Si plusieurs dossiers actifs sont équivalents, aucune sélection arbitraire n'est faite.

Le diagnostic affiche séparément la campagne WordPress, l'ID campagne legacy, le client actuellement lié et le client CRM résolu, avec les preuves de rapprochement. La Source Capturia et le UUID sélectionné restent inchangés.


## 1.11.38 — identité client CRM normalisée pour Capturia
Une campagne historique peut conserver plusieurs familles d’identifiants : ID WordPress AWM, ID Laravel legacy et ID WHMCS. Capturia ne doit jamais traiter un ID legacy ou WHMCS comme s’il était automatiquement un ID utilisateur WordPress.

Le connecteur résout désormais d’abord le client canonique associé à la campagne. Pour une campagne migrée, `_callink_legacy_campaign_id` est rapproché du paquet de migration, puis du client CRM via `_callink_legacy_user_id` ou l’adresse courriel exacte. Le statut `active / inactive / archived` est lu seulement après cette résolution. Le diagnostic Capturia montre les deux identifiants (`Campagne #… → CRM #…`) afin de rendre tout écart visible.

Cette correction vise notamment le cas où CRM AWM affiche clairement une fiche **Actif** alors que CallTracker annonçait à tort « client inactif ». Les leads importés Capturia sont également attribués au client CRM canonique résolu.

## 1.11.37 — build Capturia forcé
Cette version reprend le correctif 1.11.36 sous un numéro supérieur afin de forcer son installation lorsque le site possède déjà un ancien build portant le même numéro 1.11.36.

## Capturia — statut client corrigé
La synchronisation Capturia suit maintenant exclusivement le **statut canonique CRM AWM** du client (`active / inactive / archived`). L’approbation d’accès au portail/Core n’est plus interprétée comme un statut client : un compte portail non approuvé ne peut donc plus provoquer à tort le message « client inactif » avant même l’appel Capturia.

Dans la fiche campagne, le bloc Capturia affiche aussi **Statut client CRM** et la source utilisée pour la décision. Si CRM déclare réellement le client inactif ou archivé, la synchronisation reste suspendue conformément à la politique de cycle de vie AWM. Si CRM est actif, **Récupérer les leads** peut appeler Capturia normalement avec la Source Capturia sélectionnée.

## Capturia — menu Source + récupération ciblée des leads
Une campagne CallTracker ne demande plus à l’administrateur de copier un `source_id`. Après avoir enregistré la clé API, le bouton **Synchroniser les sources** lit `GET /v1/tags`, garde uniquement les tags Capturia de catégorie **Source** et les tags de campagne (`system_key=campaign:…`), puis les affiche dans un menu **Source Capturia**.

La source choisie est enregistrée par son UUID. **Récupérer les leads** appelle ensuite `GET /v1/contacts?tag=<UUID>` avec pagination, ce qui limite l’import aux contacts de la source choisie. Les permissions minimales sont `tags:read` et `contacts:read`. Le secret reste exclusivement côté serveur dans Core Vault.

Le taux 7 % est traité comme marqueur legacy/par défaut de resynchronisation complète : le vrai investissement Google Ads remplace la valeur historique, puis le barème AWM officiel est recalculé. Un verrou manuel hérité de migration ne protège pas une ligne qui est encore à 7 %.
Historique CPL distingue désormais les valeurs automatiques Google Ads, les règles AWM, les paramètres automatiques, les valeurs manuelles et les données legacy. Le backfill historique cible chaque mois encore à 7 %, récupère le coût réel Google Ads, remplace l’investissement historique et applique le barème officiel. Les autres composantes de coût restent conservées.
Historique CPL dispose maintenant d'un diagnostic mensuel qui montre d'un coup d'œil si l'investissement, les frais annexes et les leads sont prêts à produire un CPL fiable. Les frais récurrents (rabais de gestion, réceptionniste, autres) peuvent être enregistrés comme paramètres mensuels par campagne et appliqués automatiquement aux nouvelles lignes Google Ads. La provenance Google Ads, la devise et la date de synchronisation sont conservées lorsque seuls les frais annexes sont modifiés. La page Google Ads ajoute aussi **Synchroniser toutes les campagnes** avec progression en arrière-plan.

# CallTracker AWM 1.11.30 — actions groupées UX corrigée

## Correctif 1.11.30
Le parcours groupé utilise exclusivement le panneau métier CallTracker. Le sélecteur natif **Modification groupée** et la ligne `#bulk-edit` WordPress sont désactivés; le bouton CallTracker est placé dans la barre de filtres et ouvre un panneau pleine largeur hors du tableau. Le moteur serveur sécurisé de 1.11.29 reste inchangé.


Dans **CallTracker AWM → Campagnes**, les cases de sélection alimentent maintenant un bouton unique **Actions groupées**. Le panneau guide le technicien en trois temps : sélectionner les campagnes, choisir l’action, puis lire un aperçu serveur avant toute écriture.

Les actions courantes sont **Activer**, **Mettre en pause** et **Réattribuer**. Les opérations plus risquées — **Archiver**, **Corbeille**, **Libérer Twilio** et **Supprimer définitivement** — restent isolées dans une zone sensible avec phrase de confirmation. Le moteur ne fait confiance ni à l’interface ni à un ancien aperçu : il revalide permissions, état, client, numéro, impact historique et empreinte au moment de l’exécution.

Les lots sont limités à 50 campagnes. Les appels et formulaires ne sont jamais supprimés par les actions de cycle de vie; la suppression définitive d’une campagne détache seulement leurs références locales après conservation de l’historique. Les actions Activer / Pause ne modifient ni le routage ni Twilio.

# CallTracker AWM 1.11.28 — tri métier et vues technicien

La liste **CallTracker AWM → Campagnes** devient pilotable directement par les indicateurs métier. Les colonnes **Leads 30 j**, **Historique total** et **CPL** sont maintenant triables côté serveur, donc le tri porte sur toutes les campagnes et pas seulement sur la page visible.

Une nouvelle barre **Vue technicien** propose **Toutes**, **À vérifier**, **Sans client** et **Sans numéro**. La sélection est mémorisée par utilisateur WordPress et reste active pendant les recherches, filtres et changements de page. **À vérifier** regroupe les campagnes qui ont une erreur de synchronisation, aucun client associé ou aucun numéro principal.

# CallTracker AWM 1.11.27 — historique total visible dans Campagnes

La liste **CallTracker AWM → Campagnes** distingue maintenant la performance récente de l historique complet. La colonne **Leads 30 j** reste la lecture opérationnelle récente, tandis que **Historique total** affiche le nombre cumulé d appels et de formulaires rattachés à chaque campagne existante.

Le panneau **Détails** affiche également deux cartes séparées : **Performance 30 jours** et **Historique total**. Les totaux sont calculés directement depuis `callink_calls` et `callink_forms` pour les campagnes de la page courante, sans migration, sans réécriture de données et sans toucher à Twilio. L écart connu de 214 appels historiques reste accepté et non bloquant.

# CallTracker AWM 1.11.26 — formulaires historiques enrichis

Les captures Laravel de type **Courriel historique** stockaient souvent l’adresse d’expédition technique du site dans `from_email`, alors que le vrai courriel, le téléphone et la page d’origine étaient présents dans le corps HTML. CallTracker extrait maintenant ces données à l’affichage et peut les persister par une réparation ciblée dans **CallTracker AWM → Migration**.

La réparation ne touche pas au routage Twilio. Elle parcourt uniquement les 44 712 formulaires historiques en lots de 100, conserve les champs WordPress déjà enrichis, et utilise l’URL `web_form_capture_url` de la campagne legacy seulement lorsque le courriel historique ne fournit pas de page source explicite.

# CallTracker AWM 1.11.25 — réintégration historique réellement incrémentale

Le démarrage de la réintégration est maintenant volontairement **constant-time** : la requête de clic ne touche pas aux 180 Mo de lots historiques et ne compte pas les tables. Elle crée la session puis rend la main au navigateur. Les écritures sont ensuite traitées par lots de **100 lignes**, avec validation SHA-256 du fichier courant avant toute écriture.

L emplacement opérationnel recommandé est **CallTracker AWM → Migration**. Avec Hub AWM 4.5.65, l ancien bouton d import historique a été remplacé par ce moteur reprenable.

# CallTracker AWM 1.11.24 — démarrage réintégration sans attente

La page **Migration → Rapprochement Laravel → WordPress** démarre maintenant avec un précontrôle rapide. Le navigateur affiche immédiatement **Préparation…**, puis chaque fichier historique est contrôlé par SHA-256 juste avant son import et la progression indique **Lot source X / 115**. Cette correction évite le long pré-scan des 114 018 lignes avant le premier retour visuel tout en conservant l intégrité de la migration.

# CallTracker AWM 1.11.23 — réintégration historique contrôlée

La page **CallTracker AWM → Validation et santé** contient maintenant, dans **Rapprochement Laravel → WordPress**, un assistant pour réintégrer l’historique Laravel assigné : **69 306 appels + 44 712 formulaires**. Le paquet est vérifié avant import, puis traité par lots de 500 avec un curseur persistant. L’opération peut être interrompue et reprise sans doublons.

Les identifiants historiques restent les clés stables. Le moteur conserve les enrichissements plus récents déjà présents dans WordPress et ne modifie ni les numéros Twilio, ni le routage, ni les campagnes. Une campagne qui n’existe plus comme fiche active n’empêche pas la conservation de son historique : le `legacy_campaign_id` et le propriétaire client restent enregistrés.

# CallTracker AWM 1.11.22 — lecture audio Twilio fiable

- Le proxy sécurisé des enregistrements suit maintenant les redirections média Twilio au lieu de bloquer la réponse intermédiaire.
- Le lecteur HTML5 utilise `preload=metadata` afin d afficher la durée réelle avant la lecture.
- Le endpoint sécurisé supporte les requêtes HTTP `Range` et retourne `206 Partial Content`, `Accept-Ranges`, `Content-Range` et la longueur exacte du segment.
- Le streaming est envoyé par blocs sans exposer l URL média Twilio ni les identifiants du compte.
- Le dashboard affiche un état clair : chargement, prêt avec durée, connexion lente ou erreur de lecture.
- En cas de média absent/refusé, CallTracker affiche une erreur explicite plutôt qu un lecteur bloqué à `0:00 / 0:00`.

# CallTracker AWM 1.11.21 — synchronisation appels + formulaires

- Chaque carte campagne du dashboard contient maintenant un bouton **Synchroniser**, et chaque client déplié possède aussi **Synchroniser le client** pour traiter toutes ses campagnes.
- La synchronisation relit les appels entrants de la période directement depuis Twilio pour le numéro suivi de la campagne et importe les appels manquants dans l historique canonique.
- Les appels déjà présents sont corrigés/rattachés à la bonne campagne lorsque le numéro suivi est unique, y compris les anciennes lignes liées par `legacy_campaign_id`.
- Les soumissions de formulaires déjà reçues mais encore orphelines sont rattachées à la campagne à partir du mapping exact site + moteur + identifiant de formulaire.
- Les inventaires de formulaires des WordPress Connector concernés sont actualisés séquentiellement afin de conserver Gravity Forms, Elementor Pro Forms et Contact Form 7 à jour.
- Après synchronisation, les KPI Appels, Formulaires, Leads, Répondus, Manqués et durée moyenne sont recalculés pour la période affichée.
- Le client ouvert reste déplié après le rechargement du dashboard afin de vérifier immédiatement le résultat.
- Même si les identifiants Twilio sont temporairement incomplets, la synchronisation réconcilie d abord les appels déjà présents localement avant de signaler que l import distant Twilio reste à vérifier.

# CallTracker AWM 1.11.20 — finition dashboard client

- Dashboard clients/campagnes conservé comme vue opérationnelle principale.
- Les appels affichent maintenant un lecteur même si `recording_sid` n a pas encore été persisté; la première lecture retrouve le recording dans Twilio via le Call SID/Child Call SID puis répare l historique local.
- Les formulaires affichent directement **tous les champs stockés** (contact, coordonnées, message, champs personnalisés, UTM, page et autres valeurs du payload) au lieu d un bloc replié.
- Les formulaires historiques sans payload structuré conservent leur contenu nettoyé complet à l écran.
- Avec Core AWM 4.5.272, `callink-dashboard` reçoit le header **CallTracker AWM** et l onglet Tableau de bord actif.

## CallTracker AWM 1.11.19 — tableau de bord clients / campagnes
- Nouveau menu **Tableau de bord** dans CallTracker AWM.
- Vue principale par **client**, puis dépliage des campagnes sans changer de page.
- KPI : clients actifs, campagnes actives, appels entrants, formulaires, leads, appels répondus/manqués et CPL moyen.
- Filtres Client / Campagne / Période : aujourd’hui, 7 jours, 30 jours, ce mois, 3 mois, année et personnalisé.
- Une campagne conserve plusieurs WordPress/domaines, y compris des chemins distincts comme `/` et `/region/`, ainsi que plusieurs formulaires.
- Détail opérationnel : 30 appels récents avec lecture sécurisée Twilio et 30 formulaires récents avec source, page et contenu.
- Aucun nouveau silo de données : les campagnes, l’historique, le routage, les formulaires et le CPL existants restent les sources de vérité.

## CallTracker AWM 1.11.18 — diagnostic de synchronisation Elementor
L'assistant **Site WordPress → Synchroniser les formulaires → Choisir → Enregistrer** affiche maintenant la preuve de scan Elementor du site choisi. Si aucun formulaire n'est trouvé, il distingue clairement *Elementor Pro non actif* de *Elementor Pro actif mais aucun widget Form trouvé*.

## CallTracker AWM 1.11.17 — synchronisation guidée des formulaires
Le parcours Campagne → Formulaires devient : **Site WordPress → Synchroniser les formulaires → Choisir → Ajouter → Enregistrer**. Gravity Forms, Elementor Pro Forms et Contact Form 7 sont supportés. Une campagne peut agréger plusieurs WordPress et plusieurs formulaires par WordPress.

## CallTracker AWM 1.11.16 — formulaires persistants et détectables
- Une campagne peut relier plusieurs WordPress et plusieurs formulaires par site.
- Les sites Connector apparaissent immédiatement; l inventaire Gravity Forms/Elementor peut être actualisé depuis la campagne.
- Chaque ligne est sauvegardée comme objet `{site_url, source, form_identifier}` pour éviter les pertes lors d ajouts/retraits dynamiques.
- Un bouton « Enregistrer les formulaires » est disponible directement dans la section Formulaires.

## CallTracker AWM 1.11.15 — formulaires détectés multi-sites
- UX guidée Site WordPress → moteur → formulaire.
- Inventaire automatique Gravity Forms et Elementor remonté par Hub Client sans requête supplémentaire.
- Plusieurs sites et plusieurs formulaires peuvent alimenter une même campagne.


## Mise à jour 1.11.13 — 2026-10-01
- UX multi-formulaires par campagne et synchronisation Alliance/Hub Client simplifiée.
# Calltracker 1.11.12 — UX Campagnes Appels / Formulaires

Ajoute les onglets Appels, Formulaires et Tout afficher; permet de choisir Elementor Pro ou Gravity Forms directement dans la campagne et publie le mapping au Hub Client.

# CallTracker AWM 1.11.11 — Gravity Forms + Campagnes monoligne

La barre de contrôle de **Campagnes** est maintenant monoligne en desktop : recherche, actions groupées, filtres Client/Statut/Source et boutons partagent la même rangée. La pagination WordPress supérieure est masquée pour supprimer le bloc isolé sous les filtres; la pagination située au bas du tableau reste intacte. Sous 1100 px, les contrôles peuvent se replier proprement afin de préserver le responsive.

# CallTracker AWM 1.11.8 — Campagnes lisibles + statut direct

## Finition Campagnes 1.11.8
La liste Campagnes privilégie maintenant les informations qui doivent rester lisibles en opération : **nom complet de la campagne** et **nom complet du client associé**, avec retour à la ligne propre plutôt qu'une ellipse prématurée. Le statut n'occupe plus une colonne ni un badge `Pause` : un seul point placé à côté de la campagne indique **vert = actif** et **jaune = en pause**. Ce point est cliquable pour basculer immédiatement Actif ↔ Pause, avec nonce WordPress, contrôle de permission et journal de sécurité AWM.

La colonne **CPL** reste visible dans le tableau compact aussi longtemps que la largeur le permet et son en-tête devient sticky avec le reste des colonnes afin que le `—` d'une campagne sans lead reste toujours compréhensible. Le moteur Twilio, le routage, Capturia, Google Ads, la formule CPL et les données historiques restent inchangés.

# CallTracker AWM 1.11.7 — Campagnes responsive sans défilement horizontal

## Finition Campagnes 1.11.7
La vue Tableau s ajuste maintenant à la largeur disponible en desktop sans barre de déplacement horizontale. Le mode Compact masque progressivement les informations secondaires selon la largeur, tandis que le mode Détaillé reste disponible sur grand écran. Les clients utilisent leur favicon Hub/site au lieu d une lettre; une icône neutre remplace uniquement les favicons absentes ou invalides.


Les cinq KPI restent sur une seule rangée en desktop/laptop. Le tableau métier s adapte maintenant à la largeur disponible sans barre de déplacement horizontale : les colonnes secondaires sont masquées progressivement et les libellés longs utilisent une ellipse propre. Sur tablette/mobile, le mode **Blocs** reste prioritaire lorsqu aucune préférence utilisateur n est enregistrée.


La liste **Campagnes** conserve le CPT historique `callink_campaign`, mais remplace l expérience WordPress brute par une vue métier plus riche : KPI, client associé, source, numéro principal, routage, statut, leads/appels 30 jours, CPL et dernière activité.

Deux modes sont disponibles : **Tableau** pour la densité opérationnelle et **Blocs** pour les écrans plus étroits. Le choix est mémorisé localement et le mode Blocs devient prioritaire sur mobile/tablette. Un panneau de détail rapide permet d inspecter une campagne sans quitter la liste; l éditeur complet reste accessible par le bouton Modifier.

Cette refonte ne change aucune donnée ni règle métier : routage Twilio séquentiel, modèles, Capturia, Google Ads, CPL et historique restent inchangés.

# CallTracker AWM 1.11.2 — routage séquentiel appliqué immédiatement

CallTracker 1.11.2 conserve les modèles réutilisables et corrige leur application terrain : **Charger** applique maintenant immédiatement la copie à la campagne. Le simulateur lit aussi les valeurs visibles du formulaire afin de montrer la vraie chaîne principale → secours 1 → secours 2 avant même un enregistrement WordPress complet.

Chaque modèle conserve jusqu à cinq destinations avec nom, téléphone, priorité, état actif/inactif et délai de sonnerie. Les modèles sont limités à vingt et utilisent les mêmes permissions CallTracker que l édition de campagne.

Le moteur Twilio reste celui de 1.11.0 : destination principale puis secours séquentiels, sans sonnerie parallèle.

# CallTracker AWM 1.11.0 — Routage phase 2

CallTracker 1.11.0 étend le routage entrant sans changer la route principale existante. Une campagne peut maintenant définir jusqu à cinq destinations de débordement nommées, chacune avec priorité et délai de sonnerie. Les destinations sont appelées **séquentiellement** après échec/non-réponse de la destination principale; aucune sonnerie parallèle n est introduite.

L éditeur de campagne ajoute un bloc **Routage avancé — équipe et simulateur**. Le simulateur évalue une date/heure dans le fuseau de la campagne, affiche Ouvert/Fermé et la chaîne exacte qui serait utilisée, sans contacter Twilio. Le champ historique de débordement reste compatible et représente le premier secours de la chaîne. Les campagnes existantes gardent donc leur comportement tant qu aucune équipe supplémentaire n est configurée.

Les validations de campagne incluent maintenant la chaîne de secours dans l empreinte d approbation et détectent les doublons ou destinations identiques à la principale/hors-heures.

## 1.10.8 - validation mensuelle Capturia et pipeline

CallTracker conserve Capturia comme source distante en lecture seule. Après l import des contacts du tag de la campagne, il peut maintenant lire le pipeline Capturia et ne retenir que les opportunités dont l identifiant correspond à un contact déjà attribué à cette campagne. Cela évite d utiliser des compteurs globaux d un compte Capturia contenant plusieurs campagnes.

Une réconciliation complète du tag est aussi exécutée de façon contrôlée : les contacts retirés du tag ou supprimés dans Capturia sont retirés du décompte local uniquement après un scan complet réussi. Le CPL ne change pas : coûts totaux / (appels entrants + formulaires AWM + leads Capturia activés). Le pipeline est un KPI complémentaire : pour un mois donné, AWM affiche l état **actuel** des opportunités issues des leads créés ce mois, leur valeur et leurs étapes. Ce n est pas un historique de stage à la fin du mois.

Le test de connexion vérifie aussi `pipeline:read` et `bookings:read`. Ces permissions sont optionnelles : leur absence ne bloque pas les leads ni le CPL. Les bookings ne sont pas encore attribués à la campagne tant que le payload réel du premier client n a pas confirmé un lien fiable.

## 1.10.7 - Capturia en lecture seule pour CPL

CallTracker peut maintenant relier une campagne AWM déjà existante à un compte Capturia **sans installer Hub Client sur la landing page**. La connexion est exécutée uniquement depuis le Hub central Alliance : la clé API est chiffrée par Core AWM, puis CallTracker lit `/me`, `/tags` et `/contacts` en GET.

Les contacts importés sont conservés dans l historique canonique des leads avec `source=capturia`, un identifiant Capturia stable et leur date de création. Un tag Capturia peut isoler la campagne; si le compte est dédié à une seule campagne, la lecture de tous les contacts reste possible. Un import historique progressif est suivi d une synchronisation automatique toutes les 15 minutes.

Le CPL distingue maintenant **Formulaires AWM** et **Capturia**. Le nombre Capturia n entre dans le dénominateur que si l option **Inclure les leads Capturia dans le calcul du CPL** est activée sur la campagne. La formule reste : coûts totaux / (appels entrants + formulaires AWM + leads Capturia activés).

## 1.10.6 - Interface Google Ads professionnelle

La page **CallTracker AWM -> Google Ads** suit maintenant le shell AWM : cartes Light/Dark, etats OAuth/MCC/synchronisation, formulaires compacts et rendu responsive. Le moteur Google Ads/CPL 1.10.4/1.10.5 reste inchangé.

## Google Ads - écran de configuration 1.10.5
CallTracker possède maintenant sa propre page **CallTracker AWM -> Google Ads**. Les réglages Google Ads ne sont plus recherchés dans **Hub AWM -> Réglages**. La page permet d enregistrer OAuth, plusieurs MCC, de connecter Google, de tester un MCC et d ouvrir directement les campagnes / l historique CPL.

## Google Ads CPL - 1.10.4
CallTracker peut utiliser deux MCC ou davantage avec une seule integration Google Ads. Chaque campagne conserve son MCC (`login_customer_id`), son compte Google Ads et, au besoin, son `campaign_id`. Le cout mensuel provient de `metrics.cost_micros` et alimente l investissement CPL sans modifier la definition des leads: appels entrants admissibles + formulaires admissibles.

La synchronisation automatique traite de petits lots toutes les 15 minutes et reprend le mois courant ainsi que le mois precedent. Une erreur API ne remplace jamais un cout valide par zero. La derniere valeur reste disponible avec un etat de fraicheur et la derniere erreur pour diagnostic.

Depuis septembre 2026, le niveau d acces Google Ads API est lie au projet Google Cloud qui porte les identifiants OAuth. Le champ Developer Token historique est donc facultatif dans le moteur; une valeur deja enregistree reste envoyee pour compatibilite.

## 1.10.3 — Pulse v2 routage — 2026-09-12

- Le score Health CallTracker pénalise uniquement les erreurs de synchronisation/routage connues.
- Les campagnes et Twilio restent non modifiés automatiquement; le score sert au triage.

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

- Expose au Core un pulse campagnes actives / brouillons / erreurs de synchronisation routage.
- Le pulse reste strictement descriptif et ne déclenche aucune opération Twilio.

# CallTracker AWM 1.10.0 — parcours Funnel client piloté par CRM

CallTracker 1.10.0 sépare maintenant la commande du service et l exécution téléphonique. Le client démarre dans **Nouveaux services**, crée un Funnel à **10 $/mois** géré commercialement par CRM, choisit ensuite son numéro, récupère son webhook de formulaire puis configure son routage avancé. Le service CRM reste en configuration et non facturable automatiquement jusqu à l attribution confirmée du numéro.

Le routage client couvre la destination principale, le fuseau, les horaires, les jours fermés, la destination hors heures, le débordement séquentiel et le délai. Les secrets et opérations Twilio restent exclusivement côté Alliance/Core/CallTracker.

# CallTracker AWM 1.9.9 — Webhooks de formulaires par Funnel
CallTracker 1.9.9 fournit à chaque Funnel client un webhook HTTPS unique. Les envois provenant d Elementor, Gravity Forms, WPForms ou d un formulaire personnalisé sont attribués automatiquement au bon client et à la bonne campagne, puis stockés dans l historique de formulaires utilisé par Leads et CPL.


## Routage avancé 1.9.7

La phase 1 du Lot C ajoute des horaires par campagne, des fermetures spéciales, une destination hors heures et un débordement séquentiel. Le fuseau de campagne demeure la référence. Le secours est déclenché par une route TwiML Core signée par Twilio et ne sonne qu après échec/non-réponse de la destination initiale. Hub affiche l aperçu de la route; Validation et santé exige les essais correspondants.


CallTracker AWM 1.9.6 ajoute une procédure contrôlée pour reprendre **tous les numéros des campagnes actives et les numéros encore actifs dans l’export legacy retrouvés localement** dans AWM avant de décommissionner l’ancienne plateforme. La procédure est accessible dans **Validation et santé** et travaille par lots avec progression.

La reprise ne se contente pas de modifier WordPress : elle résout le Phone Number SID si nécessaire, replace le `VoiceUrl` Twilio sur AWM, retire les fallbacks/application voix legacy et relit ensuite la ressource Twilio pour confirmer que la bascule a réellement eu lieu. Les campagnes dont les appels entrants sont désactivés sont quand même reprises par AWM; le webhook CallTracker refuse ensuite le transfert, ce qui rend enfin le crochet de désactivation maître du comportement.

Une fois tous les numéros conformes, l’action **BASCULE AWM** verrouille les imports Laravel et CPL. L’ancienne plateforme reste consultable comme référence historique mais ne peut plus réécrire les données CallTracker sans réouverture explicite.

# CallTracker AWM 1.9.5 — resynchronisation du routage des campagnes existantes

CallTracker 1.9.5 corrige le cas des campagnes déjà existantes lorsque le numéro de réception est modifié. La sauvegarde locale ne suffit plus : CallTracker vérifie le Phone Number SID, reprend automatiquement le webhook entrant AWM chez Twilio et mémorise la destination effectivement synchronisée. Un état de routage et une action de resynchronisation manuelle sont visibles dans l'éditeur de campagne.

Le routage reste dynamique : le numéro de transfert défini dans la campagne est prioritaire; s'il est vide, le numéro de destination du client est utilisé. Une modification du numéro client resynchronise aussi les campagnes qui utilisent ce fallback. Les lots Validation et santé, Fiabilité 1.9.3 et connexion non bloquante 1.9.4 restent conservés.
Pour l’éditeur complet, Hub AWM 4.5.15 filtre aussi les requêtes Heartbeat de fond afin qu’elles n’ouvrent plus le loader « Récupération des données » toutes les ~30 secondes.

---

# CallTracker AWM 1.9.4 — éditeur de campagne sans popup WordPress

CallTracker 1.9.4 corrige le dialogue WordPress « Connexion perdue » sur les campagnes. L'autosave WordPress est retiré uniquement du CPT interne CallTracker; la barre AWM conserve l'enregistrement manuel et affiche un état de connexion non bloquant. Le lot Fiabilité 1.9.3 reste inchangé et continue sa validation terrain.

# CallTracker AWM 1.9.3 — Fiabilité des événements Twilio

CallTracker 1.9.3 consolide le lot Fiabilité et sécurité des événements après le centre Validation et santé de 1.9.2.

## Webhooks
- idempotence persistante pour `status` et `recording`;
- détection de rejeu/doublon;
- ordre monotone des statuts avec `SequenceNumber`;
- file de reprise locale pour erreurs transitoires;
- cinq tentatives maximum puis échec définitif visible;
- erreurs 4xx déterministes ignorées sans boucle de retry;
- événements TwiML observés pour rejeu mais jamais bloqués uniquement parce qu ils sont répétés.

## Temps et CPL
Les nouveaux appels/formulaires disposent d instants UTC canoniques. Les historiques sont convertis avec le fuseau de leur campagne lorsque possible. Le CPL mensuel utilise le mois civil du fuseau de campagne puis convertit ses bornes en UTC pour interroger les données.

## Enregistrements
L API cliente ne retourne plus l URL Twilio brute. Core vérifie la propriété, récupère le média côté serveur avec les secrets protégés, puis Hub Client le relaie via une URL locale de session.

## Validation et santé
Le panneau affiche les événements reçus, traités, en reprise, en échec définitif et le dernier événement UTC. Les tests réels Alliance/Twilio restent obligatoires avant approbation des campagnes et clôture de migration.

## Capturia — clé API uniquement (1.10.9)
L administrateur AWM n a pas besoin d un compte Capturia. La clé API du client est analysée côté serveur avec `/v1/me`; AWM valide ensuite `contacts:read`, charge les tags si `tags:read` est disponible et conserve les scopes/preset/expiration uniquement comme métadonnées non secrètes. Sans tag, l inclusion dans le CPL exige une confirmation explicite que tous les contacts accessibles correspondent à la campagne.


## Routage 1.11.2 — comportement attendu

- `Charger` un modèle : copie l'équipe dans le formulaire **et l'applique immédiatement aux appels réels**.
- `Appliquer l'équipe maintenant` : persiste les modifications manuelles de l'équipe sans sauvegarder les autres champs de la campagne.
- `Simuler` : utilise l'équipe actuellement affichée et liste chaque étape séquentielle avec son délai.
- Un changement manuel non appliqué est signalé visuellement pour éviter qu'un test Twilio parte avec une ancienne route.

## Routage — analyse et export (1.11.4)
La carte de performance de chaque campagne peut maintenant être filtrée sur 7, 30 ou 90 jours. Un export CSV UTF-8 reprend le résumé de la période et chaque tentative Twilio pour audit ou analyse externe. Le temps avant réponse reste volontairement absent tant qu un événement Twilio `answered` dédié n est pas horodaté : `DialCallDuration` représente la durée de conversation et ne doit pas être utilisé comme faux temps d attente. Les données restent strictement celles collectées depuis 1.11.3.

## Routage — statistiques opérationnelles (1.11.3)
Chaque callback Twilio `<Dial action>` écrit une tentative additive dans `wp_callink_route_attempts` avec la campagne, l étape, la destination, le statut Twilio et la durée. La campagne affiche ensuite les KPI sur 30 jours et le taux de réponse de chaque étape. Cette télémétrie débute avec 1.11.3 : les appels antérieurs ne sont jamais reconstruits artificiellement.

## Gravity Forms
CallTracker accepte maintenant la source distincte `hub_client_gravityforms` envoyée par Hub Client 1.14.4, ce qui permet de distinguer les leads Gravity Forms des formulaires Elementor et des connecteurs génériques.

## Multi-sites par campagne
Une campagne peut associer plusieurs WordPress et plusieurs formulaires. Chaque mapping peut cibler une URL de base exacte (chemin inclus), une source Elementor/Gravity Forms et un identifiant de formulaire.

---

## ROADMAP.md

## Maintenant - 1.11.76
- [x] Ne plus afficher Capturia comme destination manquante chez les clients non concernés.
- [x] Afficher uniquement les destinations réellement actives.
- [x] Renommer le KPI en CRM externes pour préparer plusieurs fournisseurs.
- [x] Préserver le moteur d envoi Capturia immédiat et le mapping identité 1.11.75.
- [ ] Futur : vue de preuves fournisseur-neutre (provider, contact, tag/segment, données, HTTP, request-id) sans PII.
- [ ] Terrain : VMV doit montrer Capturia; Allo Déménagement et les clients sans CRM ne doivent montrer que LeadTracker et leurs destinations réellement actives.

## Maintenant - 1.11.75
- Mapping Capturia identite v2 livre localement.
- Prochain vrai lead VMV : confirmer nom/prenom/courriel/telephone dans Capturia et preuve Contact / Google / Donnees dans LeadTracker.
- Ne pas envoyer de nouveau faux lead uniquement pour le test.
- Futur : diagnostic PII-free du mapping par lead (presence prenom/nom/email/telephone, sans valeurs).

## Livré localement — LeadTracker AWM 1.11.74 (2026-10-19)
- **Packaging runtime minimal.** Les RELEASE-NOTES/VALIDATION des anciennes versions sont sortis du plugin installé.
- **Historique protégé hors runtime.** Les archives restent dans le dépôt/archives AWM; `data/history` demeure présent tant que les outils de migration/rapprochement en dépendent.
- **Aucun changement métier.** Les fonctions 1.11.73 sont byte-for-byte conservées hors métadonnées de version et documentation.
- [ ] Valider l'import terrain via Core AWM et confirmer que la version active devient 1.11.74.
- [ ] Après validation terrain, confirmer la publication de la roadmap publique.

## Livre localement — LeadTracker AWM 1.11.73 (2026-10-19)
- **Packaging corrige.** Une seule racine `awm-calltracker/` est livree; la copie de travail dupliquee de 1.11.72 est retiree.
- **Aucun changement fonctionnel.** Les leads restent unifies Appels + Formulaires et la fiche complete au clic est preservee.
- **Garde Core respectee.** Le module extrait reste sous 600 fichiers et 256 Mo sans modifier les limites de securite.
- [ ] Valider l import terrain via Core AWM.

## Livre localement — LeadTracker AWM 1.11.72 (2026-10-19)
- **Leads = appels + formulaires.** La vue campagne utilise la meme definition que le CPL et affiche les deux sources dans une chronologie unique.
- **Fiche lead complete au clic.** Chaque formulaire expose toutes les reponses utiles et chaque appel expose details, routage et lecture protegee lorsque disponible.
- **UX lisible.** Compteurs separes Leads totaux / Appels / Formulaires, badges de type et detail en ligne sans changer de page.

## Livré localement — LeadTracker AWM 1.11.71 · Google Ads persistant + historique CPL

- [x] Mémoriser durablement MCC, compte, mode et campagnes Google Ads par campagne LeadTracker.
- [x] Déclencher automatiquement l historique complet après sélection/enregistrement d un compte Google Ads.
- [x] Réconcilier chaque mois avec le barème AWM officiel et conserver rabais/réceptionniste/autres coûts.
- [x] Conserver des instantanés mensuels auditables incluant appels, formulaires, leads, coût total et CPL.
- [x] Ne jamais effacer les lignes CPL antérieures à la fenêtre Google Ads vérifiable.
- [x] Rendre le traitement idempotent par empreinte de configuration et journaliser son état.
- [ ] Valider sur une campagne réelle que le premier backfill couvre tout l historique disponible et que les totaux Google Ads concordent avec le compte client.
- [ ] Confirmer la publication sur la roadmap publique; la page officielle était inaccessible depuis l environnement de validation.

---

## 2026-10-18 - LeadTracker AWM 1.11.70 - campagne active = synchronisation automatique

- Nouvelle règle opérationnelle : une campagne publiée dont le statut LeadTracker est `active` doit maintenir automatiquement ses entrées configurées sans clic sur « Synchroniser ».
- Numéro Twilio : à l’activation ou après une modification de campagne, LeadTracker applique le routage entrant puis relit Twilio pour vérifier que le VoiceUrl AWM est réellement actif. Les erreurs restent visibles dans `_callink_twilio_sync_error`; aucune réussite n’est inventée.
- Formulaires : pour toute campagne active ayant des associations/form capture configurées, LeadTracker rafraîchit les inventaires Hub Client, rapproche les formulaires déjà reçus et réapplique les mappings enregistrés. Aucun formulaire non rattaché n’est deviné automatiquement, sauf la règle spéciale VMV-NAT `capturia_auto_all_forms` déjà existante.
- Un worker de convergence traite les changements immédiatement en arrière-plan et recontrôle ensuite les campagnes actives par petits lots. Le numéro est revalidé périodiquement et les formulaires sont rafraîchis sans dépendre d’un opérateur.
- Les changements de statut, numéro, destination, client, mappings ou activation de capture déclenchent automatiquement la convergence de la campagne.
- Le bouton manuel « Synchroniser les formulaires » reste disponible uniquement pour forcer un diagnostic/scan immédiat.
- Hub Client 1.14.33 complète ce contrat : mappings actifs actualisés en arrière-plan et lecture fraîche obligatoire juste avant chaque vraie soumission Elementor, Gravity Forms, Contact Form 7 ou hook AWM.

# 2026-10-18 - LeadTracker AWM 1.11.69 - Capturia central live + preuve serveur

- [x] Envoyer le nouveau lead VMV-NAT depuis LeadTracker au moment de `forms/submit`.
- [x] Réutiliser le moteur d’écriture Capturia ayant déjà traité les 563 formulaires historiques.
- [x] Prouver chaque étape dans la fiche campagne sans dépendre d’un reçu distant.
- [x] Empêcher le double envoi Hub Client quand LeadTracker possède la mutation.
- [x] Conserver une finition locale des réponses complètes uniquement si le mode confidentialité est actif.
- [ ] Validation terrain sur le prochain vrai lead; aucun faux formulaire demandé.

# 2026-10-16 - LeadTracker AWM 1.11.68 - Preuve Capturia renforcée

- [x] Afficher Contact Capturia, request ID API, HTTP et heure de livraison sur chaque lead VMV-NAT.
- [x] Conserver la preuve PII-free et rattachée au `form_row_id` exact.
- [x] Ne déclencher aucun nouvel envoi depuis l'écran de preuve.
- [ ] Confirmer sur le prochain vrai lead client que la preuve passe immédiatement de `En attente` à `Confirmé`.
- [ ] Synchroniser la roadmap publique après validation terrain.

# 2026-10-16 - LeadTracker AWM 1.11.66 - Export funnel complet LeadTracker + Capturia

- [x] Inclure les leads déjà envoyés/confirmés Capturia dans l export de campagne.
- [x] Fusionner la copie Capturia avec la soumission LeadTracker quand le même lead est reconnu.
- [x] Dédupliquer par relation technique contact/formulaire, puis identité conservatrice dans une fenêtre de 24 h.
- [x] Conserver les leads Capturia-only avec provenance explicite au lieu de les perdre.
- [x] Ajouter les colonnes de preuve Capturia et provenance dans le CSV.
- [x] Respecter la sélection des formulaires et exclure seulement `capturia_unassigned`.
- [ ] Valider en production l export VMV-NAT du 2026-08-10 à aujourd hui et remettre le CSV au client.
- [ ] Synchroniser la roadmap publique dès que la page officielle est accessible.

---

# 2026-10-16 - LeadTracker AWM 1.11.65 - Export CSV campagne

- [x] Ajouter une section Export CSV dans chaque campagne.
- [x] Permettre la sélection Du/Au.
- [x] Permettre la sélection des formulaires/sources rattachés avec compte de soumissions.
- [x] Exclure les contacts importés Capturia du fichier de formulaires.
- [x] Exporter les champs de formulaire utiles sans secrets et neutraliser l'injection CSV.
- [ ] Valider en production l'export VMV-NAT depuis le 10 août 2026 et comparer le total remis au client avec l'historique LeadTracker.
- [ ] Synchroniser la roadmap publique dès que la page publique est de nouveau accessible et que la version terrain est confirmée.

---

## 2026-10-16 - LeadTracker AWM 1.11.64 - ordre d'envoi Capturia autoritaire dans forms/submit

- Corrige le cas terrain où LeadTracker recevait immédiatement le formulaire VMV-NAT mais Hub Client n'obtenait aucune preuve Capturia.
- La réponse authentifiée `forms/submit` transporte maintenant une instruction PII-free `capturia_dispatch` calculée sur Alliance pour la campagne exacte qui vient d'être enregistrée.
- Cause racine terrain supplémentaire corrigée : `connector_vmv_credential()` exigeait encore au moins un mapping formulaire individuel alors que VMV-NAT est maintenant en mode `capturia_auto_all_forms`. Cette ancienne garde pouvait accepter le lead dans LeadTracker puis refuser silencieusement la credential Capturia. La route auto-all-forms n exige plus de mapping individuel sur le WordPress principal VMV.
- Hub Client n'a plus besoin de redécouvrir l'intention Capturia via une seconde lecture de `forms/campaigns` avant l'envoi; un cache, une synchronisation de mappings ou une lecture transitoire ne peut donc plus annuler silencieusement la livraison.
- L'instruction ne contient jamais la clé API. Elle indique uniquement demandé/autorisé, campagne, mode tous formulaires et, en cas de blocage, un code/message technique.
- Si la route centrale est invalide, le prochain Hub Client peut enregistrer une preuve `Bloqué` avec la raison exacte au lieu de laisser le lead en `Sans preuve`.
- Corrige aussi le repli des anciennes clés par campagne : si VMV-NAT ne porte pas elle-même le secret mais qu une seule connexion Capturia du même client existe, le Connector réutilise cette source autorisée au lieu de retourner `clé illisible`.

## 2026-10-15 - LeadTracker AWM 1.11.63 - Capturia automatique pour tous les formulaires VMV-NAT

- Le contrat Connector annonce `capturia_auto_all_forms` pour VMV-NAT lorsque la destination Capturia est active.
- Le câblage n exige plus de sélectionner manuellement chaque formulaire VMV-NAT : Hub Client capture automatiquement les formulaires du site principal, tout en respectant une association explicite à une autre campagne.
- Activer Capturia maintient la réception LeadTracker active pour la campagne; désactiver Capturia redevient un choix explicite.
- Les preuves restent rattachées au lead exact et affichées en America/Toronto.

## 2026-10-15 - LeadTracker AWM 1.11.62 - preuve Capturia par lead et heure Toronto

- Corrige l affichage des heures VMV-NAT : les horodatages techniques restent en UTC mais la page Cablage des leads les affiche maintenant via l horloge Core America/Toronto avec HAE/HNE automatique.
- La liste des leads VMV-NAT ajoute une colonne Capturia par formulaire : Confirme, En attente, Bloque, A confirmer ou Aucune preuve technique recue.
- La preuve expose les etapes techniques Contact / Google / Donnees afin de distinguer creation du contact, etiquette et notes sans ouvrir Capturia.
- Le recu technique accepte source, identifiant de formulaire, phase et curseur de notes; il reste strictement sans nom, courriel, telephone ni contenu de formulaire.
- Le connecteur accepte un submitted_at_utc explicite. Une resoumission idempotente recente peut reconciler l heure UTC et completer nom/courriel/telephone manquants sans creer un doublon.
- Le cablage Capturia VMV-NAT accepte maintenant tout formulaire explicitement associe sur le site principal parmi Elementor, Gravity Forms et Contact Form 7; le moteur du formulaire ne peut plus etre un motif de rejet silencieux.
- Aucun historique 563 n est relance par cette version.

## 2026-10-15 - LeadTracker AWM 1.11.61 - vrai contact Elementor et séparation CRM / preuve

- Les nouveaux formulaires Hub Client utilisent le vrai **nom, courriel et téléphone** lorsque ces données existent; `Demande Web` devient le dernier recours uniquement si aucune identité exploitable n est disponible.
- Les libellés Elementor français/anglais courants sont reconnus : nom complet, prénom/nom, courriel/email, téléphone/cellulaire/mobile et variantes proches.
- En mode `local_mirror_v1`, LeadTracker conserve seulement l identité opérationnelle minimale nécessaire à l affichage et à la déduplication; les réponses complètes restent dans le miroir local chiffré et sont envoyées au CRM Capturia pour VMV-NAT.
- La table de preuve Capturia demeure sans PII et continue d afficher uniquement le statut de livraison, les identifiants techniques et les horodatages.
- Les journaux ajoutent seulement des indicateurs booléens `identity_*_present`; aucune valeur nominative n est écrite dans le journal de sécurité.
- La récupération de tous les contacts Capturia manquants de 1.11.60 est conservée sans changement.

## 2026-10-15 - LeadTracker AWM 1.11.60 - Capturia : preuve des nouveaux envois et récupération des archives manquantes

- Ajoute dans **Câblage des leads > VMV-NAT** une preuve technique des nouveaux formulaires envoyés vers Capturia : statut, identifiant de ligne AWM, identifiant contact Capturia et horodatage, sans stocker de nouvelle copie nominative dans la table de preuves.
- Ajoute **Récupérer tous les leads Capturia manquants** : AWM parcourt tous les contacts lisibles par la clé API Core de Vendre Maison Vite, compare les identifiants Capturia et les formulaires déjà connus, puis importe uniquement les contacts absents de l archive courante.
- Les contacts déjà issus des 563 formulaires historiques acceptés ou des nouveaux formulaires AWM sont reliés à leur ligne existante plutôt que dupliqués.
- Une attribution de campagne ambiguë n est jamais forcée : le contact est conservé comme **Capturia - à classer** au niveau du client et reste hors CPL jusqu à qualification.
- Le scan respecte les pauses HTTP 429 et reprend par WP-Cron / AJAX. Aucun scan ni nouvel envoi n est lancé à l installation.
- VMV-NAT reste une campagne SEO pour le CPL; `Google` reste uniquement la destination Capturia.

## 2026-10-15 - LeadTracker AWM 1.11.59 - Capturia : reprise adaptive apres HTTP 429

- La reprise historique VMV-NAT n envoie plus plusieurs formulaires simultanement : un seul formulaire est traite par passage, avec espacement des requetes d ecriture.
- Capturia HTTP 429 n est plus traite comme une erreur fatale : LeadTracker lit `Retry-After` / `RateLimit-Reset` quand disponible, applique une pause globale, puis reprend automatiquement.
- Le navigateur et WP-Cron partagent un verrou de traitement afin d eviter deux workers Capturia concurrents sur la meme campagne.
- Les lignes deja acceptees restent acquises; les lignes en attente/retry conservent leurs cles d idempotence. Aucun formulaire n est reinitialise par la mise a jour.
- Pendant un backfill actif, le bouton de verification Capturia ne lance plus de nouvelles requetes inutiles : il affiche l etat du transfert et la pause eventuelle.
- Aucun envoi Capturia n est declenche a l installation. VMV-NAT reste SEO pour le CPL et Capturia reste reserve a Vendre Maison Vite.

## 2026-10-15 - LeadTracker AWM 1.11.58 - Cablage Capturia lit correctement la cle Core

- Corrige le faux message « La cle API Capturia est absente ou illisible » dans **Cablage des leads > VMV-NAT** alors que la meme cle est validee dans Core AWM et dans la fiche campagne.
- Cause : une connexion Capturia geree par Core n appartient volontairement a aucune campagne (`campaign_id=0`). Le bouton de verification transmettait ce `0` au moteur Capturia, qui ne pouvait alors pas retrouver le client Vendre Maison Vite ni la cle Core.
- Correction : la verification utilise VMV-NAT comme contexte de campagne lorsque la credential vient de Core; le chemin historique conserve son identifiant de campagne d origine.
- L interface indique maintenant explicitement « Cle Capturia geree dans Core AWM pour Vendre Maison Vite » au lieu de « campagne #0 ».
- Aucun changement de cle, aucun envoi Capturia et aucun backfill ne sont executes a l installation. La reprise historique 564 formulaires de 1.11.57 reste manuelle et idempotente.


## 2026-10-15 - LeadTracker AWM 1.11.57 - VMV-NAT : reprise des 564 formulaires vers Capturia Google

- Ajoute une reprise historique manuelle et idempotente pour **VMV-NAT uniquement** : les formulaires deja rattaches a la campagne sont figes dans un instantane puis envoyes par lots vers Capturia avec l etiquette normale **Google**.
- Le traitement conserve un etat technique par formulaire (sans PII), reprend apres interruption et stoppe les resultats reseau incertains au lieu de rejouer aveuglement une creation.
- Les formulaires dont la source est deja `capturia` ne sont jamais renvoyes. Un formulaire sans courriel ni telephone reste bloque et visible dans le bilan.
- Avant le premier envoi, LeadTracker exige une confirmation explicite que l import historique ne declenchera pas une sequence SMS/courriel indesirable dans Capturia.
- Le statut commercial CRM **Actif/Inactif** est desormais independant des campagnes et des leads : `Inactif` ne bloque plus l activation de campagne, Capturia ou la collecte. Un dossier archive/supprime ou un rattachement non canonique reste bloque.
- La campagne reste classee **SEO** pour le CPL. La destination Capturia `Google` ne transforme pas VMV-NAT en campagne Google Ads.
- Aucun envoi n est lance a l installation : l operateur doit ouvrir Cablage des leads > VMV-NAT et confirmer la reprise.

## 2026-10-15 - LeadTracker AWM 1.11.56 - Capturia gere dans Core

- LeadTracker ne propose plus de champ pour enregistrer/remplacer la cle Capturia. Le bouton ouvre `Core AWM > Connexions > Coffre et cles`.
- Pour les campagnes du client CRM **Vendre Maison Vite**, la cle centralisee Core est lue en priorite en memoire serveur.
- Les anciennes cles chiffrees par campagne restent lisibles temporairement comme repli, sans nouvelle ecriture dans LeadTracker.
- Un remplacement de cle dans Core invalide uniquement les caches de capacites/compte/sources; aucun lead historique ni mapping CPL n est purge.
- La planification Capturia reconnait aussi une campagne active utilisant la cle Core meme si aucun ancien meta de cle n existe.
- Capturia n est pas active pour les autres clients.

## 2026-10-14 - 1.11.55 / Suite AWM 4.5.404 - CRM Clients

Nouvelle vue CRM Clients - resultats, en lecture directe sans cache nominatif. Les lecteurs et collecteurs historiques restent disponibles.

Candidate de migration additive : tests locaux, essai WordPress/MySQL et sites clients requis.
Aucun transfert a l'installation. Ne supprime ni sources historiques, ni audio Twilio.
Un seul lancement global depuis CRM AWM > CRM Clients - campagnes et leads.
Prealables : trousseau Core enrole et sauvegarde separement; Hub Client 1.14.22 sur sources et destination; autorisations techniques.
Le statut commercial et le statut des campagnes ne sont pas modifies. Capturia n'est jamais exige ni active pour les autres clients.

---

# LeadTracker AWM 1.11.54 — Statut CRM autoritaire
- [x] Retirer le faux blocage « client inactif » provoqué par les indicateurs hérités lorsque CRM canonique indique Actif.
- [x] Refuser clients supprimés, non canoniques ou vraiment inactifs sans toucher au rattachement en base.
- [ ] Vérifier en production BAR-SAL-GADS #2633 avec le vrai `client_id` de la campagne (CRM Julien Cousineau #171); si différent, corriger le lien après vérification humaine.
- [ ] Tester le bouton de campagne en activation puis pause et vérifier l'audit, sans toucher aux valeurs CPL ni à Capturia.
- [ ] Confirmer la roadmap publique.

## 1.11.53 — Correctif terrain, à valider sur Alliance — 2026-10-13
- [x] Rendre le badge « Campagne : en pause » réellement cliquable dans l'éditeur et le câblage, confirmation avant mutation.
- [x] Empêcher les inversions accidentelles lors de clics simultanés ; journaliser les changements.
- [x] Cacher Capturia lorsque la campagne n'utilise pas ce connecteur.
- [x] Tests PHP/JS de statut, de droits et de visibilité locales.
- [ ] Faire le test réel sur BAR-SAL-GADS et une campagne active, en vérifiant qu'un clic persiste après actualisation.
- [ ] Vérifier que VMV-NAT conserve son indicateur Capturia et ses historiques CPL sans effet secondaire.
- [ ] Publier l'avancement réel dans https://alliancewebmarketing.ca/hub/roadmap/ (non fait depuis le ZIP local).

## 1.11.52 — Livré localement : statuts LeadTracker sans ambiguïté — 2026-10-13
- Trois indicateurs indépendants dans l’éditeur de campagne et dans « Câblage des leads » : session WordPress Alliance, état métier `_callink_status`, Capturia lecture/écriture/validation.
- « Connexion active » n’est plus affiché comme preuve que la campagne reçoit des leads. Les campagnes en pause restent en pause, aucun lead ni CPL modifié.
- Les permissions Capturia absentes sont présentées comme « inconnues » et non comme lecture seule certaine. Une vérification en lecture ne valide jamais un envoi réel; messages d’avertissement cohérents.
- Libellés et pastilles accessibles, responsives et adaptés aux modes clair/sombre. Validation terrain et publication effective de la roadmap publique en attente.

## Phase pilote — 1.11.51 / VMV-NAT et Capturia sortant
Livré en code : édition formulaire/lead dans LeadTracker, source SEO, réconciliation manuelle, consentement d'activation, clé centrale existante utilisée sans ressaisie par Hub Client principal. À valider sur le site et dans Capturia : droits d'écriture, nature exacte de l'élément Google (étiquette normale), réception d'un prospect test et affichage des erreurs. À faire ensuite : historique Elementor non transmis et rapprochement du statut de livraison local dans le journal central.

## Livré en code — 1.11.51 · Fiche directe LeadTracker VMV-NAT (validation terrain requise)
- [x] Afficher/modifier les formulaires câblés à une campagne sur le tableau de câblage, sans passer par la fiche WordPress « Modifier ».
- [x] Lister les leads de la campagne, leurs sources et les 20 derniers détails de soumission avec origine.
- [x] Identifier les campagnes en pause et permettre leur activation avec confirmation de l'impact.
- [x] Rapprocher les soumissions Elementor non attribuées déjà présentes dans LeadTracker, sans toucher aux leads Google Ads ni à une autre campagne.
- [x] Afficher la destination Capturia/Google et proposer un test **de lecture**, avec clé chiffrée dans Core.
- [ ] Activer l'envoi sortant Capturia **seulement** après confirmation du format POST, des autorisations `contacts:write` et de l'identifiant de l'étiquette Google, avec file de retransmission idempotente et consentements.
- [ ] Récupérer les anciennes entrées qui sont encore exclusivement dans les tables locales de soumissions Elementor sur le site principal : connecteur d'import en lecture seule puis aperçu avant migration.
- [ ] Vérifier VMV-NAT #2636 sur le site réel : synchronisation du formulaire Elementor, premier lead test, historique et absence de doublons, puis publication sur la roadmap publique.

## Livré — 1.11.50 · Gestion CPL par source
- [x] SEO sans frais de gestion.
- [x] Autre : option frais de gestion Oui / Non.
- [x] Autre : frais en pourcentage ou montant fixe mensuel.
- [x] Harmonisation multi-mois avec la règle de gestion choisie.
- [x] Barème AWM limité à Google Ads.
- [x] Calcul CPL uniforme dans les vues admin/client et les tableaux de bord.
- [ ] Validation terrain : une campagne SEO, une Autre sans gestion, une Autre en pourcentage et une Autre avec montant fixe.

## Livré — 1.11.49 · CPL multi-source
- [x] Choix explicite Google Ads / SEO / Autre.
- [x] Montant mensuel fixe SEO/Autre.
- [x] Harmonisation de tous les mois et création des mois manquants.
- [x] Mise à jour portefeuille multi-source.
- [ ] Ajouter Meta Ads par API comme source automatique distincte lorsque le connecteur est prêt.

## Livré — 1.11.48 · correction terrain Google Ads
- [x] Supprimer la dépendance à `campaign.start_date` et `campaign.end_date`.
- [x] Vérifier l identité/accessibilité des campagnes avec `id + name + status` seulement.
- [x] Lire toute la fenêtre mensuelle disponible puis détecter le premier mois réellement observé.
- [x] Ne jamais créer de faux mois à 0 $ avant le premier mois Google Ads retourné.
- [x] Ne plus classer tous les anciens taux 7 % comme Google Ads « à configurer ».
- [x] Conserver les détails techniques sous un volet secondaire dans le Centre CPL.
- [ ] Validation terrain : Plancher-A-V-G-GADS + VMV-GADS doivent passer sans `UNRECOGNIZED_FIELD`.

# LeadTracker AWM 1.11.48 — historique Google Ads terrain

## Livré
- [x] Une seule action utilisateur pour toutes les années et tous les mois disponibles.
- [x] Requêtes Google Ads découpées par année pour éviter une plage historique monolithique fragile.
- [x] Repli automatique mois par mois lorsqu une tranche annuelle est refusée.
- [x] Extraction du vrai `GoogleAdsFailure` et du champ fautif lorsque Google retourne une erreur structurée.
- [x] Distinction entre CPL Google Ads à configurer et campagnes non concernées par Google Ads.
- [ ] Validation terrain sur les deux CPL Google Ads actuellement câblés avant d automatiser une exécution planifiée.

# LeadTracker AWM 1.11.46 — synchronisation globale Google Ads / CPL

## Livré — 1.11.46 · tout le portefeuille en un clic
- [x] Inventorier toutes les campagnes CPL possédant un câblage Google Ads complet.
- [x] Récupérer pour chacune toutes les années et tous les mois Google Ads disponibles sans sélectionner les périodes manuellement.
- [x] Continuer la file si une campagne échoue et afficher la campagne fautive.
- [x] Ne lancer le recalcul global final que lorsque toutes les récupérations Google Ads configurées ont réussi.
- [x] Appliquer ensuite le barème AWM 50 / 40 / 30 / 20 / 15 à toutes les lignes CPL, y compris les historiques non à 7 %.
- [x] Préserver rabais, réceptionniste, autres coûts et PPC sécurisé.
- [x] Garder les investissements sous 100 $ en À vérifier, sans inventer de taux.
- [ ] Validation terrain : lancer la synchronisation globale, laisser la file terminer, puis vérifier plusieurs campagnes et plusieurs années dans Historique CPL.


## Livré — 1.11.45 · Tous les mois Google Ads automatiquement
- [x] Récupérer tous les mois Google Ads disponibles en une seule opération.
- [x] Utiliser `segments.month` pour les longues périodes historiques au lieu de `segments.date`.
- [x] Additionner les campagnes cochées pour chaque mois puis corriger l historique CPL automatiquement.
- [x] Préserver sans écrasement les mois plus anciens que la rétention Google Ads.
- [x] Afficher clairement la période réellement récupérée.
- [ ] Validation terrain Plancher-A-V-G-GADS : lancer une seule fois et confirmer que tous les mois disponibles sont remplis/corrigés.

## Livré — 1.11.44 · Audit historique Google Ads complet
- [x] Détecter la date de début des campagnes Google Ads cochées.
- [x] Lire la dépense Google Ads par mois sur toute la période en une série agrégée.
- [x] Comparer chaque mois et corriger automatiquement tout investissement différent.
- [x] Recalculer le barème de gestion AWM lorsque l investissement est de 100 $ ou plus.
- [x] Préserver rabais, réceptionniste, autres coûts et PPC sécurisé.
- [x] Créer les mois manquants et journaliser avant/après/source/request-id.
- [x] Ne jamais écraser les lignes antérieures au début des campagnes Google Ads sélectionnées.
- [ ] Validation terrain sur Plancher-A-V-G-GADS depuis le premier mois Google Ads jusqu à octobre 2026.
## Livré — 1.11.43 · Google Ads multi-campagnes
- [x] Supporter plusieurs campagnes Google Ads pour un CPL.
- [x] Normaliser/dédupliquer la liste d IDs Google Ads.
- [x] Additionner `metrics.cost_micros` sur toutes les campagnes sélectionnées.
- [x] Réutiliser la sélection multi-campagnes pour la synchronisation normale et le backfill 7 %.
- [x] Garder la compatibilité avec le champ historique mono-campagne.
- [ ] Futur : permettre plusieurs comptes Google Ads/MCC dans un même CPL via le tableau de câblage universel.

# LeadTracker AWM 1.11.42 — socle universel de leads

## Livré — 1.11.42 · recherche du tableau de câblage
- [x] Rechercher instantanément une campagne, un client, un domaine, un formulaire, un numéro ou une source.
- [x] Rechercher aussi dans Capturia, CRM Client AWM, états et messages À vérifier.
- [x] Recherche multi-termes insensible aux accents sans rechargement.
- [x] Filtres Tous / Fonctionnels / À vérifier avec compteurs et état vide guidé.
- [x] Raccourci `/` pour placer le focus dans la recherche.
- [ ] Validation terrain : retrouver rapidement une campagne par client, domaine et numéro sur la vraie liste de 56 campagnes.

- [x] Nom produit visible **LeadTracker AWM**; compatibilité technique CallTracker conservée.
- [x] Tableau de câblage visuel des leads par campagne.
- [x] Destination **CRM Client AWM** visible lorsqu elle est appliquée au client.
- [x] Transport `local_mirror_v1` sans PII brute au centre.
- [x] Déduplication CPL par courriel/téléphone haché compatible avec le miroir local.
- [ ] Ajouter un assistant de câblage en 4 étapes pour les stagiaires.
- [ ] Contrat universel de connecteurs : formulaires, téléphonie, CRM, Ads et finance.
- [ ] Capturia sortant/bidirectionnel via le même contrat de connecteur.
- [ ] B2A Telecom comme second fournisseur téléphonie après Twilio.

# CallTracker AWM 1.11.40 — Capturia : validation et CPL sans doublon

## Livré
- [x] Afficher **Clé validée** après preuves réelles `tags:read` + `contacts:read`.
- [x] Conserver la réconciliation Capturia en UTC mais l’afficher dans le fuseau WordPress.
- [x] Dédupliquer le CPL entre formulaires AWM et leads Capturia par courriel ou téléphone, fenêtre 24 h, appariement un-à-un.
- [x] Ne supprimer aucune ligne historique : le doublon reste visible mais n’entre pas deux fois dans le CPL.
- [x] Afficher **Doublons AWM exclus** dans la validation mensuelle Capturia.

## Validation terrain
- [ ] VMV-GADS : confirmer **Profil de clé : Clé validée** sans devoir relancer manuellement « Analyser la clé API ».
- [ ] Vérifier que **Réconciliation tag** affiche la même heure locale que les autres synchronisations.
- [ ] Soumettre un même prospect au formulaire AWM et à Capturia; confirmer `Leads Capturia = 1`, `Doublons AWM exclus = 1`, `Comptés dans le CPL = 0` pour cette copie Capturia.
- [ ] Vérifier qu’un deuxième prospect distinct reste bien compté dans le CPL.

## Livré — 1.11.39 · Capturia : consolidation des doublons CRM historiques
- [x] Ne plus considérer `_callink_legacy_user_id` comme autorité suffisante si le dossier trouvé est inactif/archivé.
- [x] Rapprocher les clients legacy par nom, courriel, entreprise et téléphone.
- [x] Préférer un unique dossier CRM actif à identité forte.
- [x] Afficher les IDs campagne/client séparément et les preuves de rapprochement.
- [ ] Validation terrain VMV-GADS : **Client lié #57 → CRM #275 · Actif**, puis import réel des leads Capturia.

## Livré — 1.11.38 · Capturia : identité client canonique
- [x] Ne jamais interpréter directement un ID legacy/WHMCS comme ID utilisateur WordPress pour décider du statut CRM.
- [x] Résoudre les campagnes historiques par `_callink_legacy_campaign_id` → client legacy → client CRM canonique.
- [x] Repli exact sur `_callink_legacy_user_id`, courriel legacy et identifiants externes uniques.
- [x] Utiliser le client CRM canonique aussi pour les leads Capturia importés.
- [x] Afficher `Campagne #… → CRM #…` dans le diagnostic Capturia.
- [ ] Validation terrain VMV-GADS : CRM AWM #275 doit apparaître Actif et `Récupérer les leads` doit réellement appeler Capturia.

## Livré — 1.11.37 · Capturia : déploiement forcé du bon build
- [x] Republier le correctif CRM/Capturia sous un numéro supérieur pour éviter l’ambiguïté d’un build historique 1.11.36.
- [x] Conserver la règle **CRM actif = synchronisation autorisée**; l’approbation portail/Core ne décide plus du statut client.
- [x] Conserver le menu Source Capturia et l’import ciblé par UUID.
- [ ] Validation terrain : installer 1.11.37 depuis Suite 4.5.366 et confirmer qu’une requête Capturia part réellement sur **Récupérer les leads**.

## Livré — 1.11.36 · Capturia : statut client canonique CRM
- [x] Ne plus confondre approbation du portail/Core avec statut actif/inactif du client.
- [x] Utiliser CRM AWM comme source de vérité pour suspendre ou autoriser Capturia.
- [x] Garder la suspension si CRM déclare réellement `inactive` ou `archived`.
- [x] Afficher le statut CRM utilisé directement dans la fiche Capturia.
- [x] Conserver le menu Source Capturia et l’import ciblé `/contacts?tag=<UUID>` de 1.11.35.

## Validation terrain 1.11.36
- [ ] VMV-GADS : confirmer **Statut client CRM = Actif**.
- [ ] Cliquer **Récupérer les leads** et confirmer qu’une requête Capturia est réellement envoyée.
- [ ] Confirmer que la source **Campagne : PPC - (514) 320-3000** retourne des leads et que le compteur augmente.
- [ ] Passer un client pilote à Inactif dans CRM AWM et confirmer que Capturia est alors réellement suspendu.

## Livré — 1.11.35 · Capturia : menu Source et leads ciblés
- [x] Charger les sources depuis `GET /v1/tags` avec `tags:read`.
- [x] Afficher un menu **Source Capturia** plutôt qu’un identifiant technique à saisir.
- [x] Prioriser les tags de campagne `system_key=campaign:` et conserver aussi les autres tags de catégorie `source`.
- [x] Enregistrer le UUID de la source en interne sans l’exposer comme étape utilisateur.
- [x] Récupérer les leads uniquement par `GET /v1/contacts?tag=<UUID>` avec `contacts:read`.
- [x] Bloquer les nouvelles synchronisations sans source choisie afin d’éviter le surcomptage du compte complet.
- [ ] Validation terrain : synchroniser les sources du compte Olivier, choisir **Campagne : PPC - (514) 320-3000**, récupérer les leads et comparer le volume au Pipeline Capturia.

## Livré — 1.11.34 · 7 % = source Google Ads autoritaire
- [x] Toute ligne encore à 7 % déclenche une relecture du vrai investissement Google Ads.
- [x] Remplacer l'investissement historique par le vrai montant Google Ads avant de choisir le taux de gestion.
- [x] Appliquer automatiquement le barème AWM 50/40/30/20/15 % sur le vrai investissement.
- [x] Conserver réceptionniste, autres frais, rabais et PPC sécurisé.
- [x] Ne pas inventer de taux sous 100 $ : laisser la ligne à vérifier.
- [ ] Validation terrain sur plusieurs mois 7 % de la campagne pilote.

## Livré — 1.11.33 · backfill 7 % terrain
- [x] Cibler toute ligne à 7 % non manuelle, même après changement de provenance technique.
- [x] Relire le vrai coût Google Ads puis appliquer le barème AWM officiel.
- [x] Préserver strictement les investissements et taux manuels.
- [ ] Validation terrain sur une campagne réelle avec plusieurs mois 7 %.

## Livré — 1.11.32 · CPL provenance + backfill 7 %
- Resynchronisation contrôlée des mois legacy à 7 % depuis Google Ads.
- Priorité aux valeurs manuelles; provenance Auto/Manuel/Legacy/Règle AWM par composante.
- Audit compact avant/après dans la métadonnée CPL.

## 1.11.31 — CPL complet et automatisé
- [x] Ajouter un statut mensuel **Complet / À compléter** pour le CPL.
- [x] Afficher investissement, source, devise, fraîcheur, gestion, rabais, réceptionniste, autres, leads et CPL dans une même lecture.
- [x] Ajouter des paramètres mensuels récurrents par campagne pour rabais, réceptionniste et autres coûts.
- [x] Appliquer les paramètres automatiquement aux nouvelles lignes créées par la synchronisation Google Ads.
- [x] Préserver la provenance Google Ads lorsque seuls les frais annexes sont modifiés.
- [x] Marquer explicitement un investissement remplacé manuellement comme `manual_override`.
- [x] Fusionner les métadonnées Google Ads et les confirmations de coûts au lieu de les écraser.
- [x] Ajouter **Synchroniser toutes les campagnes** avec progression et lots de fond accélérés.
- [x] Afficher source, devise et état de complétude dans l'historique CPL.
- [ ] Validation terrain : choisir une campagne Google Ads, synchroniser le mois courant, enregistrer des frais annexes et confirmer que la source reste Google Ads.
- [ ] Validation terrain : confirmer qu'une campagne avec paramètres mensuels crée automatiquement le prochain mois avec les bons frais.
- [ ] Validation terrain : lancer la synchronisation complète Google Ads et vérifier la progression jusqu'à toutes les campagnes associées.

## 1.11.30 — UX fiable des actions groupées
- [x] Supprimer les actions groupées natives WordPress du CPT Campagnes.
- [x] Empêcher l ouverture du `#bulk-edit` natif même si un thème/extension le réinjecte.
- [x] Mettre le bouton **Actions groupées** dans la barre Recherche / filtres.
- [x] Forcer le panneau CallTracker hors du tableau et en pleine largeur responsive.
- [x] Conserver tous les garde-fous serveur de 1.11.29 sans modification métier.
- [ ] Validation terrain : sélectionner deux campagnes, confirmer que seul le panneau CallTracker apparaît et qu il occupe toute la largeur en Dark/Light à 1080p.

## 1.11.29 — actions groupées métier sécurisées
- [x] Ajouter un bouton **Actions groupées** lié aux cases de sélection de Campagnes.
- [x] Ajouter **Activer** et **Mettre en pause** comme opérations idempotentes sans modification Twilio/routage.
- [x] Exposer **Réattribuer** avec choix du client cible et propagation contrôlée campagne + historiques.
- [x] Isoler **Archiver / Corbeille / Libérer Twilio / Supprimer définitivement** dans une zone sensible.
- [x] Exiger un aperçu serveur avant toute exécution et conserver les phrases de confirmation sur les actions sensibles.
- [x] Réutiliser nonce, permission `calltracker/approve`, jeton d’aperçu à usage unique, empreinte d’état, verrous et logs Core.
- [x] Masquer les bulk actions natives WordPress sur la liste afin de garder un seul parcours métier.
- [ ] Validation terrain : sélectionner 2 campagnes pilotes, tester Aperçu puis Activer/Pause sans toucher au routage.
- [ ] Validation terrain : vérifier Réattribuer sur une campagne de test et confirmer appels/formulaires sous le nouveau client.
- [ ] Validation terrain : ouvrir la zone sensible et confirmer que Libérer Twilio/Supprimer restent bloqués sans préconditions et phrase exacte.

## 1.11.28 — tri métier et vues technicien
- [x] Ajouter le tri serveur sur **Leads 30 j** pour toutes les campagnes, pas seulement la page courante.
- [x] Ajouter le tri serveur sur **Historique total** avec appels + formulaires cumulés.
- [x] Ajouter le tri serveur sur **CPL** du mois courant en gardant la règle Capturia.
- [x] Ajouter les vues technicien **Toutes / À vérifier / Sans client / Sans numéro**.
- [x] Mémoriser la vue sélectionnée par utilisateur WordPress et la conserver avec les autres filtres.
- [x] Validation terrain : tri Leads 30 j / Historique total / CPL confirmé fonctionnel dans Campagnes.
- [x] Validation terrain : vues Toutes / À vérifier / Sans client / Sans numéro confirmées par l’exploitation.

## 1.11.27 — historique total dans Campagnes
- [x] Afficher **Historique total** directement dans la liste des campagnes existantes.
- [x] Afficher séparément le nombre cumulé d appels et de formulaires.
- [x] Conserver **Leads 30 j** comme lecture récente distincte.
- [x] Ajouter **Performance 30 jours** et **Historique total** côte à côte dans le panneau Détails.
- [x] Garder le tableau sans requête SQL par ligne grâce à des agrégats groupés sur la page courante.
- [x] Classer les 214 appels historiques manquants comme écart connu non bloquant à la demande de l exploitation.
- [ ] Validation terrain : confirmer sur VMV-NAT et Soltech qu une campagne avec historique ancien affiche immédiatement des totaux non nuls même si ses 30 derniers jours sont à zéro.

## 1.11.26 — qualité des formulaires historiques
- [x] Remplacer à l’affichage le courriel technique du site par le vrai courriel du prospect lorsque celui-ci est présent dans le contenu historique.
- [x] Extraire le téléphone historique et le présenter dans le résumé du formulaire.
- [x] Extraire `URL de la page` et utiliser `web_form_capture_url` de la campagne comme repli prudent.
- [x] Générer un payload structuré minimal (nom/courriel/téléphone/page) pour éviter `0 champ(s)` lorsque les données existent dans le courriel.
- [x] Ajouter une réparation persistante, reprenable et par lots de 100 pour les 44 712 formulaires.
- [x] Préserver l’expéditeur technique original en métadonnée interne non affichée.
- [x] Exclure les campagnes mises à la corbeille du mapping actif lors des réconciliations suivantes.
- [x] Afficher correctement « Terminée avec N erreur(s) » après une migration partielle.
- [x] Validation terrain : VMV-NAT / Luciana Bisegna affiche le vrai courriel prospect, le téléphone et la page source attendue.
- [ ] Lancer **REPARER FORMULAIRES** et confirmer la persistance des coordonnées sur un échantillon VMV, SOS Psychosocial et VVV.
- [x] Décision exploitation : conserver les 214 appels historiques refusés comme écart connu non bloquant et poursuivre sans rejouer les 114 018 lignes.

## 1.11.25 — import incrémental terrain
- [x] Faire répondre la requête de démarrage avant tout scan, hash global, `COUNT(*)` ou cartographie complète.
- [x] Descendre les écritures à 100 lignes par requête AJAX.
- [x] Conserver le SHA-256 du fichier courant juste avant écriture.
- [x] Éviter les `COUNT(*)` après chaque lot; recalcul exact à la fin/rechargement.
- [x] Optimiser les cartes utilisateur/campagne avec lectures SQL groupées.
- [x] Ajouter un timeout navigateur clair et reprise sûre.
- [x] Utiliser **Migration** comme emplacement opérationnel via Hub AWM 4.5.65.
- [ ] Validation terrain : le premier lot doit avancer après installation 1.11.25/Hub 4.5.65.
- [ ] Fermer/recharger après quelques lots et confirmer la reprise au curseur.
- [ ] Confirmer les totaux finaux 69 306 appels et 44 712 formulaires.

## 1.11.24 — réintégration historique réactive
- [x] Répondre immédiatement au clic **Démarrer la réintégration** sans relire 114 018 lignes avant le premier lot.
- [x] Précontrôler rapidement manifestes, tailles, totaux et propriétaires.
- [x] Conserver la validation SHA-256 fichier par fichier juste avant import.
- [x] Afficher le lot source courant sur 115 et un état **Préparation…** dès la première seconde.
- [ ] Validation terrain : confirmer que le premier lot démarre sur Alliance et que les compteurs avancent sans timeout.

## 1.11.23 — réintégration des 114 018 historiques
- [x] Livrer le moteur pour réintégrer 69 306 appels assignés dans `callink_calls`.
- [x] Livrer le moteur pour réintégrer 44 712 formulaires assignés dans `callink_forms`.
- [x] Vérifier les 115 lots par SHA-256 et nombre de lignes avant le premier lot.
- [x] Importer par lots de 500 avec curseur persistant et reprise après interruption.
- [x] Dédupliquer par `legacy_id` / `submission_uid` et préserver les enrichissements WordPress existants.
- [x] Prioriser le propriétaire actuel de la campagne, puis le propriétaire legacy de la campagne.
- [x] Conserver les historiques d’une campagne supprimée sans recréer la campagne.
- [x] Ajouter l’UX d’import dans Validation et santé avec progression, pause et reprise.
- [x] Validation terrain : 44 712 / 44 712 formulaires et 69 092 / 69 306 appels présents; écart de 214 appels accepté comme non bloquant.
- [ ] Contrôler ensuite les clients/campagnes à fort volume et comparer quelques appels/formulaires avec l’export Laravel.
- [ ] Après preuve terrain et sauvegarde externe de l’archive source, retirer les 188 Mo JSON décompressés des builds ordinaires et conserver un paquet migration privé séparé.

## 1.11.22 — lecture audio Twilio fiable
- [x] Suivre les redirections média Twilio dans le proxy sécurisé.
- [x] Supporter `Range` / `206 Partial Content` pour les lecteurs HTML5.
- [x] Charger les métadonnées audio afin d afficher la durée réelle.
- [x] Afficher un état clair si un recording est prêt, lent ou indisponible.
- [ ] Validation terrain : Soltech-Naturel, confirmer que les recordings de 28 s / 1 min 09 s / 1 min 22 s affichent leur vraie durée et sont lisibles avec déplacement dans la piste.

## 1.11.21 — synchronisation dashboard
- Boutons Synchroniser campagne et Synchroniser le client.
- Réconciliation appels Twilio/local et formulaires.

# CallTracker AWM 1.11.21 — synchronisation campagne

## Livré
- [x] Bouton **Synchroniser** directement sur chaque campagne du dashboard.
- [x] Backfill Twilio des appels entrants selon le numéro suivi et la période affichée.
- [x] Réattribution locale sécurisée par legacy ID puis numéro suivi unique.
- [x] Réconciliation des formulaires orphelins avec le mapping exact site/source/formulaire.
- [x] Rafraîchissement séquentiel des inventaires formulaires via Hub Client/Connector.
- [x] Recalcul immédiat des KPI après synchronisation et réouverture du client consulté.

## Validation terrain
- [ ] Soltech-Chauffe-Eau : cliquer Synchroniser et confirmer que les appels Twilio déjà reçus ne restent plus à 0.
- [ ] Soltech-Naturel : confirmer que le numéro +1 514 700-5745 conserve ses appels dans la bonne campagne.
- [ ] Confirmer que les formulaires existants restent dans leur campagne exacte sur `plomberiesoltech.com` et `/region`.
- [ ] Vérifier le retour d erreur lisible si Twilio ou un Connector est temporairement indisponible.

# CallTracker AWM 1.11.20 — dashboard terrain

## Livré
- [x] Header CallTracker AWM sur le dashboard via Core 4.5.272.
- [x] Récupération Twilio à la demande d un Recording SID absent à partir du parent/child Call SID.
- [x] Persistance locale du Recording SID retrouvé pour les lectures suivantes.
- [x] Affichage complet des champs de formulaire sans ouverture d un bloc `details`.
- [x] Grille responsive pour champs courts et messages pleine largeur.
- [x] Conservation du contenu complet des anciens formulaires e-mail lorsque le payload structuré est absent/incomplet.

## Validation terrain
- [ ] Tester ALLO-DEM-GADS : lecture d un appel `completed` dont la colonne Enregistrement était auparavant `-`.
- [ ] Tester une soumission Elementor avec nom, téléphone, courriel, message et champs personnalisés.
- [ ] Confirmer Dark/Light, 1080p et mobile.

# CallTracker AWM 1.11.19 - Dashboard clients / campagnes

## Livré
- Dashboard opérationnel regroupé par client, puis campagne.
- KPI et filtres temporels globaux.
- Sites/domaines exacts par campagne, plusieurs formulaires et plusieurs WordPress par campagne.
- Lecture des appels et inspection des formulaires directement depuis le dashboard.
- Responsive sans défilement horizontal obligatoire sur 1080p; les détails descendent en cartes sur tablette/mobile.
- CPL affiché comme valeur du mois courant et agrégé de façon pondérée.

## Maintenant
- Valider visuellement le dashboard avec plusieurs clients réels, dont une campagne possédant plusieurs WordPress (`/` + `/region/`).
- Confirmer le comptage Répondus/Manqués sur des appels récents disposant des tentatives de routage 1.11.x.
- Confirmer la lecture de quelques enregistrements Twilio depuis le panneau Appels.

## Prochaines étapes
- Comparaison de période et variation par client/campagne.
- Export PDF/Excel du dashboard filtré.
- Qualification de lead et conversion finale afin de distinguer lead brut, lead qualifié et vente.
- Vue Health AWM réutilisant ces agrégats sans dupliquer les données.

# CallTracker AWM 1.11.18 — diagnostic Elementor
- [x] Afficher l'état Elementor Pro du WordPress sélectionné.
- [x] Afficher le nombre de documents Elementor analysés quand aucun formulaire n'est détecté.
- [x] Conserver la synchronisation ciblée par site sans requêtes simultanées supplémentaires.

## CallTracker AWM 1.11.17 — livré / validation terrain
- [x] Assistant par site avec synchronisation explicite et ciblée.
- [x] Sélection multiple des formulaires détectés avant enregistrement.
- [x] Contact Form 7 ajouté comme moteur natif détectable et attribuable.
- [x] Conservation du multi-sites, multi-formulaires et des chemins WordPress distincts.
- [ ] Valider sur SEO Naturel : racine + /region, avec Gravity Forms / Elementor / CF7 selon les plugins présents.

## CallTracker AWM 1.11.16 — livré / validation terrain
- [x] Persister plusieurs lignes de formulaires sans décalage entre champs dynamiques.
- [x] Afficher les WordPress Connector avant même la première remontée de formulaires.
- [x] Actualiser manuellement la détection sans lancer plusieurs requêtes simultanées.
- [x] Conserver `/` et `/region` comme installations distinctes dans une même campagne.
- [ ] Valider sur SEO Naturel : `plomberiesoltech.com` + `plomberiesoltech.com/region`, Gravity Forms + Elementor.

## CallTracker AWM 1.11.15 — formulaires détectés multi-sites
- UX guidée Site WordPress → moteur → formulaire.
- Inventaire automatique Gravity Forms et Elementor remonté par Hub Client sans requête supplémentaire.
- Plusieurs sites et plusieurs formulaires peuvent alimenter une même campagne.


## Mise à jour 1.11.13 — 2026-10-01
- UX multi-formulaires par campagne et synchronisation Alliance/Hub Client simplifiée.
# UX Campagnes Appels / Formulaires — 1.11.12

**Livré :** Ajoute les onglets Appels, Formulaires et Tout afficher; permet de choisir Elementor Pro ou Gravity Forms directement dans la campagne et publie le mapping au Hub Client.

**Validation terrain :** confirmer le parcours sur un site pilote avant généralisation à toute la flotte.

- [x] Réception native des conversions Gravity Forms via Hub Client 1.14.4 avec source distincte.
## 1.11.11 — Gravity Forms natif / validation terrain
- Barre outils Campagnes réellement monoligne en desktop, y compris avec les styles natifs WordPress.
- Recherche et tous les filtres partagent le même conteneur flex; aucun élément n est repoussé sur une seconde ligne à largeur desktop normale.
- Responsive mobile conservé sans scroll horizontal obligatoire.

## 1.11.9 — livré / validation terrain
- [x] Mettre la barre Recherche / actions / filtres sur une seule ligne en desktop.
- [x] Supprimer le bloc pagination supérieur qui apparaissait sous la barre.
- [x] Conserver uniquement la pagination du bas de la liste.
- [x] Garder un comportement responsive propre sous 1100 px et sur mobile.
- [ ] Valider terrain à 1920, 1600, 1440 et 1366 px en Dark/Light.

# Roadmap — CallTracker AWM

## 1.11.8 — livré / validation terrain
- [x] Afficher le nom complet de la campagne sans ellipse prématurée.
- [x] Afficher le nom complet du client associé et conserver la favicon.
- [x] Supprimer le badge/colonne Pause pour redonner de la largeur au contenu métier.
- [x] Point de statut unique : vert actif, jaune pause.
- [x] Clic direct sur le point pour basculer Actif ↔ Pause avec permissions, nonce et journal AWM.
- [x] Garder CPL visible en Compact et ajouter un en-tête sticky pour identifier les colonnes pendant le défilement vertical.
- [ ] Valider terrain la bascule statut sur une campagne pilote puis plusieurs campagnes.
- [ ] Vérifier Dark/Light à 1920, 1600, 1440, 1366 et 1280 px avec noms clients/campagnes longs.

## 1.11.7 — livré / validation terrain
- [x] Supprimer la barre de déplacement horizontale du tableau Campagnes en desktop/laptop.
- [x] Ajuster automatiquement les colonnes dans la fenêtre avec densité Compact / Détaillé.
- [x] Masquer progressivement les colonnes secondaires avant tout overflow.
- [x] Garder les informations essentielles visibles : campagne, client, numéro, routage, statut, activité et actions principales.
- [x] Remplacer les initiales clients par favicon Hub / favicon détectée / favicon.ico, avec icône neutre en repli.
- [x] Conserver le mode Blocs pour tablette/mobile.
- [ ] Valider terrain à 1920, 1600, 1440, 1366 et 1280 px en Dark/Light.
- [ ] Confirmer la qualité des favicons sur les clients sans favicon manuelle.

## 1.11.6 — livré / validation terrain
- [x] Garder les 5 KPI Campagnes sur une seule rangée en desktop/laptop.
- [x] Ajouter compression contrôlée + scroll horizontal tactile plutôt qu'un retour 3+2.
- [x] Stabiliser la barre Recherche / filtres / actions / pagination sur 1366 px, 1080p et tablette.
- [x] Préserver la lisibilité du tableau par largeur minimale + scroll horizontal en mode Tableau.
- [x] Conserver le basculement Tableau / Blocs et le mode Blocs mobile.
- [ ] Valider terrain en Dark/Light sur 1366 px, 1080p, tablette et mobile.

## 1.11.5 — livré / validation terrain
- [x] Refaire le listing Campagnes en UX professionnelle et responsive.
- [x] Ajouter client associé, source/type, numéro, routage, statut, leads/appels 30 jours, CPL et activité.
- [x] Ajouter KPI globaux et filtres client/statut/source.
- [x] Ajouter modes Tableau / Blocs avec préférence mémorisée et adaptation mobile.
- [x] Ajouter un panneau de détail rapide sans casser le CPT/éditeur existant.
- [ ] Valider visuellement sur Alliance en Light et Dark avec 56+ campagnes réelles.
- [ ] Valider la densité sur 1366 px, 1080p et mobile.

## Ensuite
- [ ] Ajouter tri métier serveur sur Leads 30 j, Appels 30 j et CPL.
- [ ] Ajouter filtres enregistrés par technicien et vues « À vérifier », « Sans client », « Sans numéro ».
- [ ] Ajouter actions groupées métier directement dans la nouvelle barre sans exposer la complexité WordPress.
- [ ] Ajouter comparaison de campagnes et tendances 30/90 jours dans le panneau de détail.

## 1.11.4 — livré / validation terrain
- [x] Ajouter filtres 7 / 30 / 90 jours aux performances de routage.
- [x] Ajouter export CSV des performances et tentatives Twilio.
- [ ] Ajouter le temps moyen total avant réponse avec un horodatage Twilio `answered` dédié; ne pas dériver ce KPI de `DialCallDuration`.
- [ ] Valider les trois périodes sur une campagne active et ouvrir le CSV dans Excel/LibreOffice.

## Ensuite
- [ ] Ajouter export PDF propre au client avec résumé, KPI et étapes.
- [ ] Afficher dans la fiche client Hub les performances par campagne et les destinations les plus sollicitées.
- [ ] Ajouter un modèle lié, distinct du mode copie, avec prévisualisation avant propagation.
- [ ] Détecter automatiquement une destination peu performante et proposer une optimisation, sans changer la route sans validation humaine.

# CallTracker AWM 1.11.2 - routage séquentiel terrain

## Livré
- Bibliothèque de modèles de routage réutilisables dans l éditeur de campagne.
- Enregistrement de l équipe courante comme modèle global CallTracker.
- Chargement d un modèle en copie indépendante sur une campagne.
- Suppression contrôlée d un modèle; maximum vingt modèles.
- Conservation du simulateur et du routage séquentiel multi-destination 1.11.0.

## Maintenant
- Valider un modèle réel « Réception + 2 secours » sur deux campagnes distinctes et confirmer que les modifications restent indépendantes.
- Valider le routage Twilio terrain : principale sans réponse → secours 1 → secours 2.

## Prochaines étapes
- Statistiques de réponse par étape de routage : tentatives, réponses, taux de récupération et temps moyen avant réponse.
- Option de modèle lié, distincte du mode copie, avec prévisualisation de l impact avant propagation.
- Bibliothèque de modèles par type d équipe : réception, ventes, urgence et soir/fin de semaine.

# CallTracker AWM 1.11.0 - Routage phase 2

## Livré
- Jusqu à cinq destinations de débordement par campagne, avec nom, priorité, activation et délai de sonnerie.
- Chaîne Twilio strictement séquentielle : destination principale puis secours triés par priorité; aucune sonnerie parallèle.
- Compatibilité avec le champ historique `overflow_destination`, conservé comme premier secours de la chaîne.
- Simulateur de route dans l éditeur : date/heure locale, état Ouvert/Fermé et ordre exact des destinations, sans appel Twilio.
- Validation santé étendue : doublons, collisions avec destination principale/hors-heures, nombre de tentatives et empreinte d approbation.
- Les appels déjà lancés sous la route 1.10.x restent compatibles avec `stage=primary/overflow`.

## Maintenant
- Tester une campagne pilote avec deux destinations de secours : laisser la principale sonner sans réponse puis confirmer l ordre des deux débordements.
- Simuler une plage ouverte et une plage fermée avant le test réel.
- Vérifier que l approbation Validation et santé devient à revoir lorsqu une équipe est modifiée.

## Prochaines étapes
- Modèles de routage réutilisables par type de client/équipe, sans dupliquer les numéros dans chaque campagne.
- Stratégies supplémentaires seulement après validation terrain du séquentiel (rotation, groupes), avec garde-fous contre les boucles.
- Rapports sur taux de réponse par étape de la chaîne.
- Capturia bookings reste bloqué jusqu à observation du payload réel.

# CallTracker AWM 1.10.9 - connexion Capturia par clé seule

## Livré
- Aucun accès utilisateur Capturia requis : la clé API fournie par le client est la seule entrée nécessaire.
- Analyse automatique de la clé : compte, preset, scopes, expiration et droits réellement disponibles.
- `contacts:read` validé avant toute synchronisation; `tags:read` recommandé pour isoler la campagne, pipeline/bookings restent optionnels.
- Tags chargés automatiquement quand le scope le permet; absence de `tags:read` expliquée dans l interface sans casser la connexion.
- Garde-fou CPL : « Tous les contacts » exige une confirmation explicite, sinon les leads restent hors dénominateur.

## Maintenant
- Sur le premier client : coller uniquement la clé, cliquer « Analyser la clé API » et vérifier le compte/scopes détectés.
- Si `tags:read` est disponible, sélectionner le tag de campagne proposé par l API puis synchroniser.
- Si `tags:read` manque, demander au client une clé Lecture seule (`*:read`) ou confirmer Tous les contacts uniquement si la clé/compte est réellement dédié à cette campagne.
- Comparer un mois complet de leads et CPL après cette attribution.

## Prochaines étapes
- Après validation terrain, mémoriser des profils Capturia réutilisables si plusieurs campagnes d un même client utilisent la même clé.
- Ajouter le rapprochement RDV uniquement après confirmation du payload réel `bookings`.

# CallTracker AWM 1.10.8 - validation Capturia / pipeline

## Livré
- Validation mensuelle Capturia visible sur la campagne et dans Historique CPL.
- Pipeline Capturia lu en lecture seule et rapproché uniquement des contacts déjà attribués à la campagne AWM.
- Réconciliation quotidienne du tag afin que les suppressions/retraits Capturia ne restent pas artificiellement dans le dénominateur du CPL.
- Opportunités actuelles, valeur pipeline et répartition par étape pour les leads créés durant le mois sélectionné.
- Détection des capacités `pipeline:read` et `bookings:read` sans rendre ces scopes obligatoires pour le CPL.
- Une absence de scope/forfait pipeline est isolée comme diagnostic; les contacts Capturia continuent de synchroniser normalement.

## Maintenant
- Sur le premier client Capturia : enregistrer la clé dans la campagne existante, tester la connexion, sélectionner le tag, synchroniser puis comparer un mois pilote Capturia ↔ AWM.
- Confirmer que le nombre de leads Capturia du mois et le CPL correspondent au tableau Capturia.
- Vérifier si `pipeline:read` est disponible avec la clé fournie et comparer les étapes/valeurs sur quelques contacts.

## Prochaines étapes
- Après observation du payload réel `GET /v1/bookings`, définir un rapprochement RDV fiable par contact/projet avant d afficher un coût par rendez-vous.
- Ajouter les KPI Capturia validés à Health AWM sans modifier la définition canonique du lead/CPL.
- Webhooks uniquement comme accélérateur temps réel; l API de lecture reste la reprise fiable.

# CallTracker AWM 1.10.7 - Capturia lecture seule / CPL

## Livré
- Connecteur Capturia serveur-à-serveur sur une campagne AWM existante, sans installation sur la landing page.
- Secret Capturia chiffré par Core Vault et appels API strictement en lecture pour cette première version.
- Test de connexion, chargement des tags, choix du tag de campagne, synchronisation manuelle et automatique toutes les 15 minutes.
- Import historique progressif et synchronisation incrémentale avec déduplication par identifiant Capturia.
- Source `capturia` visible séparément dans les Leads et dans le tableau CPL.
- Option par campagne pour inclure/exclure Capturia du calcul du CPL sans perdre l historique importé.

## Maintenant
- Installer sur alliancewebmarketing.ca et valider la vraie clé API du premier client Capturia.
- Comparer sur un mois pilote le nombre de contacts Capturia du tag choisi avec le tableau Capturia avant de considérer le CPL terrain comme validé.

## Prochaines étapes
- Ajouter, lorsque le besoin est confirmé, les KPI Capturia de pipeline/rendez-vous en lecture seule sans modifier la formule CPL de base.
- Prévoir des webhooks Capturia comme accélérateur temps réel seulement si les payloads/signatures sont validés; l API de lecture doit rester le mode de reprise fiable.

# CallTracker AWM 1.10.6 - Google Ads UX alignee sur AWM

## Livre
- Page Google Ads/CPL entierement harmonisee avec le shell AWM Light/Dark.
- Statuts OAuth, MCC et synchronisation visibles en tete.
- Formulaires OAuth, MCC, test et actions CPL rendus en cartes coherentes et responsive.
- Aucun changement de donnees, OAuth ou formule CPL.

## Maintenant
- Valider visuellement la page Google Ads sur Alliance en Dark et Light.
- Configurer les deux MCC puis tester chacun d eux.
- Associer une campagne pilote et comparer un mois de cout Google Ads au CPL.

## Prochain lot accelere
- Finaliser la mise a jour AWM depuis Core pour module seul ou Suite complete sans retomber dans une longue requete Recovery synchrone.
- Ajouter progression et journal de mise a jour visibles dans le tableau de bord.

# CallTracker AWM 1.10.5 - Google Ads visible dans CallTracker

## Livré
- Page **CallTracker AWM -> Google Ads** enregistrée par le module lui-même.
- OAuth Google, MCC multiples, état de connexion et test d accès aux comptes clients visibles au même endroit.
- Régression Hub 4.5.57 contournée sans déplacer la propriété métier Google Ads hors de CallTracker.
- Le moteur CPL multi-MCC 1.10.4 est conservé sans changement de formule ni suppression de données.

## Maintenant
- Configurer les deux MCC réels.
- Connecter OAuth et tester chacun des MCC.
- Associer une campagne pilote, synchroniser un mois puis comparer l investissement avec Google Ads.
- Valider le CPL sur appels entrants + formulaires avant généralisation.

## Prochain lot accéléré
- Afficher source, devise, fraîcheur et dernière erreur directement dans les tableaux CPL.
- Synchronisation globale avec progression non bloquante.
- Backfill historique contrôlé et rapports PDF/Excel.

# CallTracker AWM 1.10.4 - Google Ads CPL multi-MCC

## Livre
- Google Ads API v25 utilisee comme source automatique de l investissement CPL.
- Plusieurs MCC geres dans la meme integration avec `login_customer_id` propre a chaque campagne.
- Synchronisation du mois courant et du mois precedent en petits lots WP-Cron toutes les 15 minutes.
- Source CPL `google_ads`, devise, derniere synchro, `request-id`, statut et erreur conserves.
- Les erreurs API conservent la derniere valeur valide et marquent les donnees Ads comme perimees au lieu d ecrire zero.
- Le Developer Token historique reste compatible mais n est plus obligatoire dans le moteur; l acces API depend du projet Google Cloud associe a OAuth.
- Schema CPL etendu de facon additive, sans toucher aux lignes historiques Laravel.

## Maintenant
- Configurer les deux MCC dans Google Ads puis verifier que le meme compte OAuth voit bien les deux hierarchies.
- Associer une campagne pilote a MCC -> compte -> campagne Google Ads.
- Executer une synchro manuelle du CPL, comparer le montant avec Google Ads puis laisser le cron reprendre automatiquement.
- Valider les appels entrants + formulaires du meme mois avant de generaliser aux autres campagnes.

## Prochaines etapes
- Afficher clairement dans Hub la source Google Ads, la devise et la fraicheur sur chaque ligne CPL.
- Ajouter un profil OAuth supplementaire uniquement si un MCC exige une identite Google differente.
- Backfill controle des mois plus anciens et rapport d anomalies depense/leads.
- Rapports CPL signes et planifies.

## Futur public
- Attribution Google Ads plus fine par annonce/mot-cle lorsque le rapprochement est fiable.
- Comparaison CPL CallTracker avec conversions Google Ads sans changer la definition AWM du lead.
- Anomalies de depense et variations CPL explicables dans Health AWM.
- Meta Ads et autres sources payantes via le meme contrat de cout.

---

# Awm Calltracker 1.10.3 — Pulse v2 routage

## Livré
- Le score Health CallTracker pénalise uniquement les erreurs de synchronisation/routage connues.
- Les campagnes et Twilio restent non modifiés automatiquement; le score sert au triage.

## Prochain lot accéléré
- Routage phase 2 : équipes, priorités, fallbacks, modèles et simulateur avant publication.
- Rapports CPL planifiés et anomalies Google Ads explicables.

# CallTracker AWM 1.10.2 — Pulse opérationnel transversal

## Livré
- Expose au Core un pulse campagnes actives / brouillons / erreurs de synchronisation routage.
- Le pulse reste strictement descriptif et ne déclenche aucune opération Twilio.

## Prochain lot accéléré
- Routage phase 2 : équipes, priorités, fallbacks, modèles et simulateur avant publication.
- CPL et Google Ads : planification de rapports, anomalies et recommandations explicables.

# CallTracker AWM 1.10.1 — statut CRM canonique

## Livré
- Filtre opérationnel centralisé sur le statut actif CRM.
- Aucune suppression de campagne, appel, audio ou historique lors d'une désactivation.
- Réactivation sans recréation des liaisons existantes.

# Roadmap — CallTracker AWM 1.10.0

## Livré — parcours Funnel client

- parcours client structuré **Nouveaux services → Nouveau funnel → Configuration du numéro → Formulaire/Webhook → Routage**;
- CRM crée et possède le service Funnel à 10 $/mois avant toute opération Twilio;
- CallTracker prépare une campagne technique en brouillon reliée au service CRM;
- le service demeure en configuration et sans facturation automatique jusqu à l attribution confirmée du numéro;
- achat/attribution du numéro sur le funnel existant avec revalidation Twilio juste avant la transaction;
- webhook de formulaire conservé comme étape 3 du parcours;
- routage client avancé : destination principale, fuseau, horaires, jours fermés, destination hors heures, débordement et délai;
- permissions et propriété du client revalidées côté serveur à chaque étape.

## Maintenant

- installer la Suite 4.5.79 sur Alliance et exécuter un funnel pilote complet;
- confirmer qu un funnel sans numéro reste non facturé automatiquement dans CRM;
- acheter un numéro réel puis confirmer activation CRM, campagne, formulaire et CPL;
- valider le routage client avec ouvert, fermé et débordement réel;
- poursuivre la validation de bascule historique et du Lot C phase 1 déjà ouverte.

## Prochaines étapes

- Lot C phase 2 : équipes, priorités, plusieurs niveaux de secours, modèles réutilisables et simulation avant publication;
- Lot D : connecteurs de formulaires supplémentaires et rapprochement;
- Lot E : synchronisation planifiée Google Ads, anomalies d attribution et rapports CPL.

---

# Roadmap — CallTracker AWM 1.9.9

## 1.9.9 — Funnel / Webhook de formulaire

- Livré : webhook HTTPS unique et secret généré pour chaque Funnel CallTracker.
- Livré : activation automatique de la structure formulaire après achat du funnel.
- Livré : réception POST JSON ou formulaire depuis Elementor, Gravity Forms, WPForms et intégrations personnalisées.
- Livré : attribution automatique au client et à la campagne du funnel.
- Livré : stockage dans l historique CallTracker, puis intégration aux Leads et au CPL.
- Livré : dédoublonnage par identifiant d envoi et protection anti-rejeu courte.
- Livré : état du dernier formulaire reçu et test de configuration non destructif.
- Hub Client 1.10.2 : onglet Formulaires avec URL à copier et documentation d installation.
- Prochaine livraison rapide : configuration complète du routage avancé depuis Hub Client.

# Roadmap — CallTracker AWM 1.9.8

## 1.9.8 — Hub Client / Numéros et Funnel

- Livré : recherche sécurisée de numéros disponibles depuis Hub Client.
- Livré : achat client confirmé d un numéro et création automatique de la campagne.
- Livré : liaison au service CRM Funnel CallTracker à 10 $/mois.
- Livré : structure 1 numéro + 1 formulaire par funnel.
- Sécurité : aucune clé Twilio n est exposée; Core revalide le numéro immédiatement avant l achat.
- Prochaine livraison rapide : routage avancé complet modifiable depuis le Hub Client.


## Analyse
La base 1.9.6 sait reprendre les numéros de l ancienne plateforme et choisir dynamiquement la destination principale. Le prochain manque opérationnel est le routage métier : la campagne doit pouvoir savoir si elle est ouverte ou fermée, respecter son fuseau, tenir compte des fermetures spéciales et tenter un secours sans appeler plusieurs destinations en parallèle.

## Objectif
Livrer la première phase du Lot C avec un comportement déterministe et vérifiable : horaires par campagne, jours fériés, destination ouverte/fermée, débordement séquentiel et aperçu de la route effective. La logique reste dans CallTracker; Core expose seulement la route publique sécurisée et Hub présente l interface d administration.

## Livré
- horaires hebdomadaires par campagne, avec activation indépendante et fuseau de campagne;
- plages pouvant traverser minuit;
- jours fériés / fermetures spéciales saisis explicitement au format `YYYY-MM-DD`;
- destination principale inchangée : override campagne puis numéro client;
- destination hors heures facultative; en son absence, CallTracker ferme proprement l appel;
- destination de débordement facultative, obligatoirement différente des destinations principales;
- débordement **séquentiel** après `busy`, `no-answer`, `failed` ou `canceled`, jamais de sonnerie parallèle;
- délai avant débordement configurable de 10 à 60 secondes;
- nouvelle route TwiML Core `callink/v1/routing-next`, protégée par la signature Twilio;
- aperçu dans Hub de l état Ouvert/Fermé, de l heure locale, de la destination effective et du secours;
- Validation et santé enrichie avec horaire, route actuelle, fermeture, débordement et délai;
- empreinte de validation étendue : toute modification du nouveau routage invalide une approbation devenue obsolète;
- tests guidés supplémentaires pour horaires et débordement.

## Maintenant
- installer la Suite 4.5.76 sur Alliance;
- exécuter la bascule/validation réelle 1.9.6 qui reste non clôturée;
- sur une campagne pilote, tester une plage ouverte et confirmer la destination principale;
- tester une plage fermée avec destination hors heures, puis une fermeture sans destination;
- provoquer une non-réponse de la destination initiale et confirmer que seule la destination de débordement sonne ensuite;
- tester une plage qui traverse minuit et une date de fermeture spéciale;
- confirmer dans Validation et santé que les nouvelles règles invalident/recréent correctement l empreinte d approbation.

## Prochaines étapes
### Lot C — Routage avancé phase 2
- équipes et groupes de destinations;
- priorités et stratégies de tentatives;
- plusieurs niveaux de secours contrôlés;
- modèles de routage réutilisables;
- aperçu simulé à une date/heure choisie et test avant publication.

### Lot D — Formulaires
- connecteurs directs supplémentaires;
- rapprochement manuel des formulaires/orphelins;
- reprise chiffrée à rétention courte pour Connector.

### Lot E — CPL / Google Ads
- synchronisation planifiée des coûts réels;
- rapprochement MCC / compte / campagne;
- contrôles d anomalies et qualité d attribution;
- rapports CPL signés et planifiés.

## Règle
Le routage avancé ne doit jamais masquer l état réel : la route est évaluée dans le fuseau de campagne à chaque appel. Le secours est séquentiel afin de préserver les statuts, l attribution et le CPL. Les validations terrain restent obligatoires avant clôture.

---

# Roadmap — CallTracker AWM 1.9.6

## Analyse
La Suite 4.5.43 sait resynchroniser une campagne existante individuellement, mais la décommission de l’ancienne plateforme exige une reprise contrôlée de **tous** les numéros actifs. Une campagne dont les appels entrants sont désactivés doit aussi repasser sous le webhook AWM afin que l’ancien système ne puisse plus continuer à router en arrière-plan; CallTracker applique ensuite l’état désactivé localement.

## Objectif
Faire une bascule unique et vérifiable : inventaire local + Twilio, reprise par lots de tous les numéros des campagnes actives et les numéros encore actifs dans l’export legacy retrouvés localement, suppression des fallbacks/application voix legacy, vérification distante, puis verrouillage des imports Laravel/CPL pour conserver l’ancienne plateforme uniquement comme référence historique.

## Livré
- nouveau bloc **Bascule ancienne plateforme** dans Validation et santé;
- aperçu des campagnes actives, numéros, destinations, états Twilio et blocages avant modification; les numéros actifs dans l export legacy sans campagne locale sont bloquants;
- reprise par lots avec progression AWM, sans popup navigateur;
- résolution automatique du Phone Number SID manquant à partir du numéro E.164;
- reprise du `VoiceUrl` vers `callink/v1/incoming` et du callback de statut AWM;
- suppression du `VoiceFallbackUrl` et du `VoiceApplicationSid` afin qu’un échec ne rebascule pas sur l’ancienne plateforme;
- vérification directe du numéro Twilio après écriture : numéro, VoiceUrl, méthode POST, absence de fallback/application legacy;
- tous les numéros des campagnes actives et les numéros encore actifs dans l’export legacy retrouvés localement sont repris, y compris lorsqu’un crochet entrant est désactivé; dans ce dernier cas AWM garde le numéro mais refuse la redirection vers le client;
- destination dynamique inchangée pour les campagnes actives avec entrants autorisés : override campagne puis numéro client;
- verrou final **BASCULE AWM** : l’ancienne plateforme devient référence historique et les imports Laravel/CPL sont refusés;
- réouverture exceptionnelle protégée par confirmation explicite et journal Core;
- journalisation campagne par campagne et journal global de finalisation;
- état de bascule, empreinte et source historique conservés pour audit.

## Maintenant
- installer la Suite 4.5.44 sur Alliance;
- ouvrir **CallTracker → Validation et santé → Bascule ancienne plateforme**;
- lancer **Resynchroniser tous les numéros actifs AWM et les numéros legacy actifs retrouvés localement** et corriger uniquement les lignes bloquantes;
- vérifier qu’un numéro avec appels entrants désactivés ne transfère plus l’appel après reprise;
- vérifier au moins trois campagnes actives par appel réel, dont une campagne utilisant le numéro de réception du client et une avec override campagne;
- lorsque `À synchroniser = 0`, `Bloquants = 0` et qu aucun numéro actif legacy ne manque localement, saisir **BASCULE AWM** pour verrouiller l’ancienne plateforme;
- poursuivre les essais Messages 1/2, enregistrement, Dialer, CPL et approbation par campagne avant clôture complète de migration.

## Prochaines étapes
### Lot C — Routage avancé
- plages horaires par campagne et jours fériés;
- destination ouverte / fermée;
- débordements et destinations de secours;
- équipes, priorités et stratégies de tentatives;
- aperçu et test avant publication.

### Lot D — Formulaires
- connecteurs directs supplémentaires;
- rapprochement manuel des formulaires/orphelins;
- reprise chiffrée à rétention courte pour Connector.

### Lot E — CPL / Google Ads
- connexion Google Ads désormais disponible côté Alliance après approbation API;
- rapprochement des coûts réels par MCC / compte / campagne;
- contrôles d’anomalies et qualité d’attribution;
- rapports CPL signés et planifiés.

## Règle
Après la finalisation de la bascule, Laravel n’est plus une source synchronisable. Les numéros Twilio actifs doivent pointer vers AWM; les campagnes désactivées restent sous contrôle AWM mais sans transfert. Toute réouverture d’un import historique est une action exceptionnelle, explicite et journalisée.

---

# Roadmap — CallTracker AWM 1.9.5

## Analyse
Les campagnes migrées ou déjà provisionnées pouvaient conserver un webhook Twilio historique. Modifier le numéro de réception dans WordPress mettait bien à jour la métadonnée locale, mais ne garantissait pas que le numéro Twilio existant repasse par le webhook AWM. Le symptôme est un ancien numéro de réception qui continue de sonner malgré la modification visible dans la campagne.

## Objectif
Faire de toute modification critique d'une campagne existante une opération de routage vérifiable : la configuration locale reste la source de vérité, et CallTracker s'assure que le numéro Twilio est bien rattaché au webhook entrant AWM avant de considérer la route comme synchronisée.

## Livré
- resynchronisation automatique des campagnes existantes après modification du routage;
- empreinte SHA-256 de la configuration pour éviter les appels API Twilio inutiles;
- validation/résolution du Phone Number SID à partir du numéro de campagne lorsqu'il manque ou n'est plus associé au numéro courant;
- webhook Twilio remis sur `callink/v1/incoming` et callback de statut AWM;
- priorité `numéro de transfert campagne → numéro client`;
- changement du numéro client propagé aux campagnes qui utilisent le fallback client;
- bloc de santé du routage dans l'éditeur avec destination effective, destination synchronisée, date et erreur;
- bouton **Resynchroniser maintenant** pour reprise manuelle;
- journal sécurité Core pour succès/échec sans bloquer la sauvegarde WordPress;
- Hub AWM 4.5.15 filtre les requêtes Heartbeat/autosave de fond afin que l’éditeur reste stable entre deux actions utilisateur;
- toute modification de destination invalide naturellement l'approbation Validation et santé via l'empreinte de campagne existante.

## Maintenant
- retester la campagne existante `servicescomptables.com` après changement du numéro de réception;
- confirmer dans l'éditeur que **Destination effective** et **Dernière destination synchronisée** sont identiques;
- faire un appel entrant réel sur le numéro Twilio et vérifier que seul le nouveau numéro de réception sonne;
- confirmer que le Phone Number SID et le webhook distant correspondent au numéro affiché;
- poursuivre les tests terrain Messages 1/2, enregistrement, Dialer et CPL avant approbation/clôture.

## Prochaines étapes
### Lot C — Routage avancé
- plages horaires par campagne;
- destinations de débordement;
- équipes, priorités et stratégies de routage;
- états hors heures et règles de secours vérifiables.

### Lot D — Formulaires
- connecteurs directs supplémentaires;
- rapprochement manuel des formulaires/orphelins;
- reprise chiffrée et à rétention courte pour livraisons Connector échouées.

### Lot E — CPL et attribution
- rapprochement coûts Google Ads;
- rapports CPL signés et planifiés;
- contrôles de qualité et anomalies par période/client.

## Règle
Une modification locale d'une campagne existante n'est considérée opérationnelle que lorsque son routage Twilio est resynchronisé ou qu'une erreur explicite est affichée. Le numéro de réception n'est jamais figé dans Twilio : Twilio appelle AWM, puis AWM choisit dynamiquement la destination courante.

---

## Historique

# Roadmap — CallTracker AWM 1.9.4

## Analyse
L'éditeur de campagne historique reste un CPT WordPress interne. WordPress chargeait encore son autosave classique et produisait le dialogue « Connexion perdue », ensuite capturé comme erreur plein écran par le loader AWM. Ce comportement n'est pas adapté à un objet métier CallTracker et peut faire croire que l'enregistrement est bloqué même lorsque le formulaire manuel reste utilisable.

## Objectif
Conserver la barre d'enregistrement AWM comme unique interaction visible, supprimer l'autosave local WordPress sur les campagnes et présenter l'état de connexion de façon non bloquante, tout en poursuivant les validations terrain du lot Fiabilité 1.9.3.

## Livré
- autosave WordPress retiré uniquement sur les écrans `callink_campaign`;
- Heartbeat conservé pour la session/verrouillage;
- dialogue natif « Connexion perdue » et notice de stockage local supprimés de l'éditeur CallTracker;
- état de connexion intégré à la barre d'enregistrement AWM;
- reconnexion automatique de l'indicateur avec événements navigateur `online/offline`;
- état Heartbeat instable affiché sans empêcher une sauvegarde manuelle;
- aucun brouillon de campagne copié volontairement dans `localStorage` par CallTracker;
- Hub AWM 4.5.14 et le loader Core de secours ignorent ces notices WordPress transitoires au lieu de les convertir en erreur plein écran.

## Maintenant
- confirmer sur Alliance qu'une perte Heartbeat n'ouvre plus de modal et que la barre revient à **Connexion active** après reprise;
- vérifier que l'enregistrement manuel fonctionne après une alerte Heartbeat transitoire;
- si Heartbeat continue de tomber, vérifier `admin-ajax.php`, WAF/ModSecurity, proxy et délais serveur sans masquer le diagnostic;
- poursuivre le centre Validation et santé : rapprochement Laravel, appels entrants/sortants, Messages 1/2, destination, enregistrement, Dialer et CPL;
- approuver les campagnes et clôturer la migration uniquement après preuves terrain.

## Prochaines étapes
### Lot C — Routage avancé
- plages horaires par campagne;
- destinations de débordement;
- équipes, priorités et stratégies de routage;
- états hors heures et règles de secours vérifiables.

### Lot D — Formulaires
- connecteurs directs supplémentaires;
- rapprochement manuel des formulaires/orphelins;
- reprise chiffrée et à rétention courte pour livraisons Connector échouées.

### Lot E — CPL et attribution
- rapprochement coûts Google Ads;
- rapports CPL signés et planifiés;
- contrôles de qualité et anomalies par période/client.

## Règle
Une campagne CallTracker est un objet métier interne : aucune fenêtre WordPress native ne doit remplacer l'interface AWM. Les vraies pertes de connectivité restent visibles sous forme d'état non bloquant et doivent être diagnostiquées plutôt que masquées.

---

## Historique

# Roadmap — CallTracker AWM 1.9.3

## Analyse
Le centre Validation et santé de 1.9.2 encadre la migration et l approbation CPL. Le risque suivant se situe dans les callbacks Twilio eux-mêmes : doublons/rejeu, statuts reçus hors ordre, écritures locales temporairement indisponibles, dates historiques non normalisées et exposition directe des médias Twilio.

## Objectif
Rendre les événements téléphoniques idempotents et récupérables, conserver une chronologie UTC canonique tout en calculant le CPL dans le fuseau de chaque campagne, et faire lire les enregistrements au client sans exposer URL Twilio ni identifiants.

## Livré
- registre persistant des événements Twilio `status` et `recording` avec clé d idempotence SHA-256;
- détection des doublons/rejeu et journalisation sécurité sans double écriture;
- observation anti-rejeu des routes TwiML `voice`/`incoming` sans bloquer un retry légitime de Twilio;
- états d appel monotones et prise en charge de `SequenceNumber` afin qu un événement ancien ne fasse pas régresser un appel terminé;
- file de reprise locale courte pour les erreurs transitoires, temporisation progressive, cinq tentatives et état échec définitif;
- erreurs déterministes 4xx marquées ignorées sans boucle de reprise;
- indicateurs Reçus, Traités, En reprise, Échec définitif et dernier événement UTC dans Validation et santé;
- colonnes UTC canoniques pour appels et formulaires avec conversion des historiques selon le fuseau de la campagne;
- calcul CPL par mois civil dans le fuseau de chaque campagne, avec bornes converties en UTC;
- stockage du dernier numéro de séquence et du dernier instant UTC de mise à jour;
- proxy Core sécurisé des enregistrements : vérification du client, récupération Twilio côté serveur et aucun URL média/secret Twilio exposé au navigateur;
- Hub Client lit les enregistrements via son propre proxy de session et affiche les heures dans le fuseau de la campagne.

## Maintenant
- exécuter le centre Validation et santé sur l installation Alliance et corriger les exceptions de migration;
- tester des callbacks Twilio dupliqués et hors ordre sur une campagne pilote;
- provoquer une indisponibilité locale contrôlée et confirmer En reprise → Traité puis le comportement échec définitif;
- tester entrant, destination, Messages 1/2, enregistrement et lecture sécurisée depuis Hub Client;
- tester un appel Dialer sortant et confirmer son exclusion du CPL;
- comparer plusieurs fins/débuts de mois dans différents fuseaux et valider les CPL;
- approuver les campagnes seulement après preuve terrain et signer la clôture de migration ensuite.

## Prochaines étapes
### Lot C — Routage avancé
- plages horaires par campagne;
- destinations de débordement;
- équipes, priorités et stratégies de routage;
- états hors heures et règles de secours vérifiables.

### Lot D — Formulaires
- connecteurs directs supplémentaires;
- rapprochement manuel des formulaires/orphelins;
- reprise chiffrée et à rétention courte pour livraisons Connector échouées.

### Lot E — CPL et attribution
- rapprochement coûts Google Ads;
- rapports CPL signés et planifiés;
- contrôles de qualité et anomalies par période/client.

## Futur
- SLA et seuils d alerte par client/campagne;
- qualité automatisée des enregistrements et politiques de consentement;
- attribution multicanale, transcription et résumé sous politiques de conservation;
- tests synthétiques automatisés de bout en bout et bascule fournisseur.

## Règle
Une campagne non approuvée demeure administrable, mais son CPL n est pas exposé au client. Les callbacks Twilio sont traités de façon idempotente; seuls les échecs transitoires sont rejoués. L UTC est la référence de stockage et le fuseau de campagne gouverne l affichage et les périodes métier. Les médias Twilio restent derrière Core.

---

# Roadmap — CallTracker AWM 1.9.0

## Analyse
L’audit de la 1.8.1 a montré que la couleur du lien `Toutes` restait incorrecte parce que WordPress rend cette navigation hors du formulaire ciblé par le CSS. Les réglages historiques d’enregistrement, Dialer et fuseau existaient aussi dans les données Laravel mais n’étaient pas encore administrables de façon cohérente dans la fiche client.

## Objectif
Finaliser le routage de campagne et rendre l’interface Campagnes fiable en clair/sombre sans modifier la compatibilité historique ni la formule CPL.

## Livré
- Correctif CSS direct de `.subsubsub`/`Toutes` en clair et sombre.
- Message 1 et Message 2 conservés avec MP3 privés Alliance.
- Numéro de réception modifiable selon les droits existants.
- Enregistrement des appels entrants activable/désactivable par campagne.
- Dialer client activable/désactivable par campagne.
- Fuseau horaire par campagne avec proposition CRM/WHMCS et défaut `America/Toronto` pour le Québec.
- RecordingStatusCallback Twilio vers Core et mise à jour de l’historique canonique.
- Appels sortants toujours exclus du CPL.
- Exclusions persistantes de campagnes supprimées revalidées.

## Travaux actuels
- Exécuter la migration réelle et comparer les compteurs historiques avec la source Laravel.
- Tester un appel entrant enregistré, un appel non enregistré, un appel sortant et le CPL résultant.

## Prochaines étapes
- Plages horaires de routage, débordement et équipes.
- Diagnostics qualité des enregistrements et consentements par territoire.

## Futur
- Transcription/résumé avec politique de conservation.
- Attribution multicanale et contrôle qualité automatisé.


---

## Historique des roadmaps précédentes

# Roadmap — CallTracker AWM 1.8.1

## Analyse

La migration Laravel/CPL de 1.7.0 est conservée. Le prochain risque opérationnel se situait dans la téléphonie réelle : les appels du Dialer étaient encore journalisés dans le post type historique alors que le Hub Client lit `callink_calls`, et l’ancien CallTracker possédait des messages vocaux avant redirection qu’il fallait restaurer sans exposer de fichiers ni ouvrir les campagnes d’un autre client.

## Objectif

Rendre le routage entrant et le Dialer cohérents entre Alliance et le Hub client, permettre l’autonomie contrôlée du client sur son Message 2 et sa destination, et garantir que les appels sortants restent visibles sans influencer le CPL.

## Livré

- **Contraste du listing Campagnes** : surfaces AWM partagées, texte/filtres/pagination lisibles en clair et sombre, sans fond noir opaque.

- Message 1 Alliance avec MP3 par défaut et remplacement administratif.
- Message 2 optionnel avec MP3 client, activation/désactivation et suppression.
- Numéro de réception modifiable par campagne par Alliance ou le client autorisé.
- Ordre TwiML Message 1 → Message 2 → Dial.
- Stockage MP3 privé, validation de taille/type, SHA-256, URL Core signée et journalisation.
- Persistance idempotente des nouveaux appels Twilio dans `callink_calls`; statut/durée mis à jour par webhook.
- Appels sortants affichés comme Sortant, exclus des leads et du CPL.
- Métadonnées historiques de routage conservées pendant la migration.

## Travaux actuels

- Test réel Twilio d’un appel entrant avec Message 1 seul, puis Messages 1+2.
- Test du changement de numéro de réception depuis Hub et vérification de la redirection suivante.
- Test d’un appel Dialer client et confirmation de sa présence dans Appels avec direction Sortant.
- Vérification de CPL avant/après appel sortant afin de confirmer l’absence d’impact.

## Prochaines étapes

- Plages horaires de routage et destinations de débordement.
- Écran de rapprochement manuel des historiques orphelins.
- Indicateurs de disponibilité/échec de lecture audio Twilio.
- File de reprise courte pour événements téléphoniques transitoires.

## Futur

- Routage par équipe et rotation.
- Transcription/contrôle qualité avec consentement et rétention.
- Détection des appels indésirables.
- Webhooks sortants vers CRM clients.

---

## Historique conservé

# Roadmap — CallTracker AWM 1.7.0

## Analyse

Le dump Laravel est plus récent que le lot précédemment emballé et confirme que l’objet des courriels ne suffit pas à attribuer sûrement tous les formulaires. Il révèle aussi des appels dont l’ancien client diffère du propriétaire actuel de la campagne. La campagne canonique doit donc déterminer l’accès et les éléments ambigus doivent rester en quarantaine.

## Objectif

Achever une migration réexécutable et vérifiable, fournir le CPL aux clients à partir d’une formule cohérente et recevoir les nouveaux formulaires directement par campagne sans dépendre d’une boîte commune.

## Livré

- Lot Laravel rafraîchi, manifeste et audit d’intégrité.
- Import clients, campagnes, numéros et CPL dans l’outil Migration existant.
- Import par lots de 69 306 appels et 44 712 formulaires attribuables.
- Réattribution canonique de 25 351 appels avec identifiant Laravel conservé.
- Quarantaine de 2 396 éléments sans campagne certaine.
- Formulaire AWM intégré et connecteur Hub Client/Elementor.
- Stockage central dans `callink_forms`, idempotence et filtrage des champs sensibles.
- CPL client fondé sur appels entrants plus formulaires.
- Flux courriel conservé comme repli.

## Travaux actuels

- Sauvegarde et exécution sur le WordPress Alliance réel.
- Validation des compteurs, avertissements, campagnes exclues et lignes manuelles.
- Comparaison de CPL connus avant ouverture aux clients.
- Essai Elementor et formulaire AWM en HTTPS avec une campagne de préproduction.

## Prochaines étapes

- Écran de rapprochement manuel des orphelins avec aperçu et approbation.
- File de reprise chiffrée et à rétention courte pour livraisons Connector échouées.
- Connecteurs directs supplémentaires pour Contact Form 7, Gravity Forms et WPForms.
- Confirmation documentaire du traitement de PPC sécurisé.

## Futur

- Constructeur de formulaires AWM avec champs configurables et consentement.
- Téléversements sécurisés avec analyse, taille/type autorisés et expiration.
- Attribution multicanale entre visite, formulaire, appel et résultat CRM.
- Rapports CPL signés, planifiés et exportables par client.

---

## Roadmap historique conservée

# Roadmap — CallTracker AWM

## Lot 1.6.0 — Actions groupées sécurisées — 2026-08-19

### Analyse
L’audit de la version stable 1.5.1 a confirmé deux parcours existants à conserver : les actions historiques de campagne dans **Hub → Rattachement campagnes** et les réservations unitaires dans **Numéros et campagnes**. Les traitements groupés d’archivage et de suppression ne présentaient toutefois aucun aperçu serveur, ne revalidaient pas l’état avant écriture et ne protégeaient pas un lot contre le rejeu ou une exécution concurrente. Une mise à la corbeille par mise à jour directe du statut pouvait aussi contourner le hook WordPress chargé de créer l’exclusion legacy.

### Objectif
Permettre à un utilisateur possédant le niveau CallTracker **Approuver** de traiter plusieurs campagnes ou réservations seulement après un aperçu précis des conséquences, une confirmation explicite et une revalidation complète, sans supprimer les appels ou formulaires historiques et sans permettre la réimportation d’une campagne supprimée.

### Livré
- Sélection de 50 campagnes ou 100 numéros au maximum par lot; les dépassements et numéros invalides sont refusés.
- Aperçu calculé côté serveur avec éléments admissibles, blocages, avertissements, compteurs d’appels/formulaires et conséquences Twilio.
- Confirmation exacte sensible à la casse, nonce, niveau **Approuver**, jeton d’aperçu à usage unique valable dix minutes et revendiqué atomiquement, empreinte HMAC de l’état et verrou atomique par ressource; les lots campagne qui modifient un numéro verrouillent aussi la ressource téléphonique.
- Revalidation de l’état juste avant l’écriture; pour les réservations, l’inventaire Twilio est relu sans utiliser le cache de l’aperçu.
- Campagnes : archiver, mettre à la corbeille, libérer le numéro Twilio, supprimer définitivement une campagne déjà à la corbeille ou réattribuer campagne, appels et formulaires à une fiche cliente autorisée.
- Numéros : réserver localement, réattribuer une réservation locale ou la retirer, sans modifier l’achat, la propriété, la facturation ou la configuration du numéro chez Twilio.
- Le client cible d’une réservation est revalidé côté serveur avec l’éligibilité CallTracker canonique afin qu’un identifiant forgé ne contourne pas la liste proposée par Hub.
- Conservation des appels et formulaires. Lors d’une suppression définitive, les références locales de campagne sont détachées et un instantané d’audit est conservé.
- Exclusion legacy persistante lors de la corbeille et de la suppression définitive, y compris pour les anciens parcours qui modifient directement le statut WordPress; l’opération destructive est bloquée si cette protection ne peut pas être relue après écriture.
- Journalisation Core du lot, de chaque élément, des refus, des résultats partiels et des anomalies de nettoyage local après une libération Twilio.
- Écritures sérialisées pour les options partagées de réservations, d’exclusions legacy et d’instantanés de suppression, avec verrou global ciblé et relecture de persistance.
- Après un `DELETE` Twilio accepté, vérification distincte de l’état local et du retrait de réservation; une anomalie est remontée sans prétendre annuler l’opération externe.
- Réattribution contrôlée : propriétaire relu après écriture, ancienne réservation restaurée si l’écriture principale échoue et propagation des appels/formulaires comptée pour détecter tout historique non déplacé.
- Interface Hub responsive et accessible avec aperçu, conséquences, phrase de confirmation et résultat campagne par campagne ou numéro par numéro; les actions unitaires historiques demeurent disponibles.

### Travaux actuels
Valider le lot sur un WordPress de préproduction relié au compte Twilio Alliance : rôles, nonces, aperçu expiré, double soumission, conflits concurrents, erreur réseau Twilio, résultat partiel, corbeille/restauration et conservation réelle des historiques.

### Prochaines étapes
- Ajouter des tests d’intégration WordPress automatisés pour les actions AJAX et les migrations d’exclusion.
- Ajouter une vérification guidée des numéros locaux dépourvus de SID Twilio valide avant une suppression définitive.
- Durcir les webhooks Twilio par une protection anti-rejeu dédiée aux requêtes signées, distincte du jeton d’aperçu administratif.

### Futur
- Règles d’acheminement par horaires, équipes et débordement.
- Modèles de campagnes validés et déploiement contrôlé.
- Alertes de coût, de numéro inutilisé et d’incohérence persistante.
- Attribution multicanale et contrôle qualité des appels avec consentement et conservation explicites.

---

## Éditeur Campagnes métier — 1.5.1 — 2026-08-19
- **Analyse :** l’écran natif WordPress affichait encore « Modifier l’article », « Ajouter un article », un bandeau de mise à jour et la boîte Publier/Visibilité, ce qui suggérait à tort qu’une campagne était du contenu public.
- **Objectif :** conserver les identifiants techniques historiques tout en présentant la campagne comme un objet CallTracker strictement interne.
- **Éléments livrés :** libellés Modifier/Ajouter une campagne, suppression de la boîte Publier, barre « Enregistrer la campagne », sauvegarde dans le loader AWM, vues de statuts éditoriaux masquées et colonne « Dernière modification ». Résultat attendu : aucune notion de publication publique n’apparaît dans le parcours campagne.
- **Travaux actuels :** validation de création, modification, corbeille, restauration et sauvegarde sur WordPress réel.
- **Prochaine étape :** actions groupées avec aperçu avant archivage, suppression, libération ou réattribution.
- **Améliorations futures :** extraire progressivement l’éditeur des composants WordPress historiques tout en conservant les routes et identifiants pour compatibilité.

## Inventaire Twilio — 1.5.0 — 2026-08-19
- **Analyse :** le gestionnaire permettait de rechercher et acheter des numéros, mais ne donnait pas une vue fiable de tous les numéros déjà détenus ni des incohérences entre Twilio et les campagnes locales.
- **Objectif :** obtenir une source opérationnelle unique pour savoir si chaque numéro est Libre, Réservé, Attribué ou À vérifier, sans exposer les secrets Twilio ni corriger silencieusement les données.
- **Éléments livrés :** lecture serveur de l’inventaire Twilio, rapprochement avec toutes les campagnes, dernier rattachement, filtres/recherche, réservations locales, détection des doublons et orphelins, journalisation et invalidation de cache après achat/libération. Résultat attendu : identifier immédiatement les numéros disponibles, utilisés et incohérents.
- **Travaux actuels :** validation sur le compte Twilio Alliance réel et revue des lignes « À vérifier » avant toute correction.
- **Prochaine étape :** actions groupées avec aperçu pour archiver, supprimer, libérer ou réattribuer plusieurs campagnes/numéros.
- **Améliorations futures :** règles de réservation avec expiration, responsable et alertes de numéro inutilisé ou facturé sans campagne.

## Hub Client et Dialer canonique — 1.4.1 — 2026-08-18
- **Analyse :** les campagnes historiques pouvaient être visibles dans CallTracker mais refusées par le Dialer lorsque leur ancien `client_user_id` différait de la fiche CRM/WHMCS canonique.
- **Objectif :** permettre au client de téléphoner uniquement avec ses propres campagnes, y compris ses alias historiques sûrs, sans assouplir le cloisonnement.
- **Éléments livrés :** validation via le résolveur Core, conservation des exigences campagne active/Dialer/numéro, attribution des nouveaux appels sortants à la fiche canonique. Résultat attendu : les campagnes historiques reconnues dans `/hub/` sont réellement utilisables par le Dialer lorsqu’elles sont autorisées.
- **Travaux actuels :** essais microphone, appels sortants et statuts Twilio depuis un vrai domaine client HTTPS.
- **Prochaine étape :** diagnostic par campagne du motif exact lorsqu’un Dialer est indisponible.
- **Améliorations futures :** choix de destination récente et favoris propres au client sans persister de données sensibles côté navigateur.

## Harmonisation administration — 1.4.0 — 2026-08-18

- **Livré :** CallTracker AWM 1.4.0 devient la référence officielle du shell visuel AWM partagé. Son ancien en-tête spécifique est remplacé par le shell Core afin d’éviter les doublons tout en conservant toutes les routes et fonctions existantes.
- **Travaux actuels :** validation visuelle sur WordPress réel en clair/sombre et sur téléphone/tablette. Résultat attendu : aucun débordement horizontal et aucune double navigation.
- **Prochaines étapes :** convertir progressivement les tableaux et formulaires historiques restants vers les composants partagés. Résultat attendu : mêmes actions, espacements et états dans tous les écrans.
- **Améliorations futures :** préférences d’affichage et accessibilité clavier/WCAG communes. Résultat attendu : personnalisation contrôlée sans divergence entre modules.


## Sécurité 1.3.7 — 2026-08-17

- CallTracker AWM 1.3.7 utilise le coffre Core 4.4.0 pour protéger au repos les secrets Twilio et Google Ads sans modifier les routes historiques.
# Roadmap — CallTracker AWM

## Analyse
Le module doit gérer le cycle de vie des campagnes et des numéros sans supprimer l’historique des appels et formulaires.

## Objectif
Rendre l’inventaire Twilio fiable et chaque opération irréversible explicite, confirmée et journalisée.

## Éléments livrés
- **Inventaire Twilio à quatre états — 1.5.0.** Résultat attendu : distinguer Libre, Réservé, Attribué et À vérifier à partir du compte Twilio réel et des campagnes locales, avec dernier rattachement et anomalies explicites.
- **Protection anti-résurrection des campagnes — 1.3.5.** Résultat attendu : toute campagne historique mise à la corbeille ou supprimée reste exclue des prochaines synchronisations avec l’ancienne plateforme, sauf restauration explicite.
- **Rapprochement global Clients ↔ WHMCS — 1.3.3.** Résultat attendu : analyser l’ensemble des anciennes fiches CallTracker, fusionner en lot les correspondances sûres vers la fiche WHMCS canonique et laisser les cas ambigus en révision manuelle sans perdre campagnes, appels ni formulaires.
- **Correctif écran Campagnes et associations historiques — 1.3.3.** Résultat attendu : n’afficher qu’un seul logo CallTracker en haut, obtenir un éditeur/liste lisible en clair et sombre et retrouver les campagnes d’un client malgré une ancienne référence technique sûre.
- **Onglet Clients dans CallTracker.** Résultat attendu : rechercher les clients directement depuis le module, filtrer Actifs/Inactifs/Tous et ouvrir rapidement leur dossier sans dupliquer la base CRM/WHMCS.
- **Activation CallTracker par client.** Résultat attendu : activer ou désactiver l’accès téléphonie sans toucher au statut WHMCS, puis rattacher directement une campagne ou en créer une nouvelle avec le client présélectionné.
- **Permissions granulaires.** Résultat attendu : séparer consultation, opérations, approbation et configuration.
- **Journal central des signatures refusées.** Résultat attendu : détecter une intégration défaillante ou abusive sans saturer la base.
- **Diagnostic des webhooks et du Dialer.** Résultat attendu : repérer une clé, une route ou une configuration manquante.

## Travaux actuels
- **Archivage et libération contrôlée.** Résultat attendu : retirer une campagne active tout en conservant appels et formulaires.
- **Suppression définitive après archivage.** Résultat attendu : empêcher la suppression prématurée d’une campagne encore attribuée.

## Prochaines étapes
- **Suppression multiple avec aperçu.** Résultat attendu : confirmer les numéros libérés et les relations conservées avant traitement.
- **Protection anti-rejeu Twilio.** Résultat attendu : bloquer une requête signée répétée hors de sa fenêtre autorisée.

## Améliorations futures
- **Acheminement avancé et modèles de campagnes.** Résultat attendu : déployer plus vite des configurations cohérentes.
- **Transcription et contrôle qualité.** Résultat attendu : mesurer la qualité des appels avec des règles de conservation explicites.
- **Attribution multicanale et alertes de budget.** Résultat attendu : relier les dépenses aux appels, formulaires et résultats commerciaux.

## Livré — 1.3.3
- Rapprochement global de toutes les anciennes fiches CallTracker vers les clients WHMCS canoniques; les cas sûrs peuvent être traités en lot et les cas ambigus restent à vérifier.
- Correction du véritable écran WordPress Campagnes : logo historique dupliqué supprimé et palette complète harmonisée.
- Campagnes historiques reconnues dans la fiche canonique par identifiant WHMCS ou courriel sûr.
- Compteurs clients agrégés sur les références techniques sûres du même client.

## Livré — 1.3.2
- Campagnes associées visibles dans chaque fiche client.
- Compteurs Appels/Formulaires par campagne et historique complet accessible depuis Campagnes.
- Palette Campagnes harmonisée et logo CallTracker replacé en haut.
## Livré — 1.3.4
- **Rapprochement d’affichage global des campagnes historiques.** Résultat : chaque fiche client CallTracker retrouve les campagnes de ses anciennes références sûres, y compris lorsque l’adresse courriel locale a changé mais que le domaine d’entreprise et l’identité concordent.
- **Sécurité anti-fausse association.** Résultat : aucun domaine grand public et aucun nom seul ne suffisent à rattacher une campagne; les consolidations permanentes ambiguës restent en révision.


## Livré — 1.3.5
- **Liste d’exclusion persistante des campagnes supprimées.** Résultat : une campagne historique à la corbeille ou supprimée définitivement ne peut plus être recréée automatiquement par une synchronisation legacy.
- **Restauration explicite uniquement.** Résultat : seule une restauration volontaire retire le marqueur d’exclusion et permet le retour d’une campagne.
- **Journalisation.** Résultat : les exclusions et restaurations sont consignées dans le journal de sécurité lorsque Core AWM est disponible.

## Livré — 1.3.6
- **Routes Twilio centralisées dans Core.** Résultat attendu : CallTracker ne publie plus directement de routes REST; Core conserve `/token`, `/voice`, `/incoming` et `/status` et délègue le traitement au module.

## Travaux actuels
- **Validation des webhooks réels après centralisation.** Résultat attendu : confirmer signatures, TwiML, appels entrants et statuts Twilio sur WordPress réel.

## Prochaines étapes
- **Actions groupées avec aperçu.** Résultat attendu : archiver, supprimer, libérer ou réattribuer plusieurs campagnes/numéros seulement après une prévisualisation claire des impacts.

## Améliorations futures
- **Diagnostic de liaison Core ↔ CallTracker.** Résultat attendu : afficher clairement lorsqu’une route Core est disponible mais que le module ou sa configuration Twilio ne l’est pas.


## 1.11.2 — livré

- Application immédiate d'un modèle chargé à la campagne.
- Bouton d'application directe pour les équipes modifiées manuellement.
- Simulateur basé sur l'état courant du formulaire, avec chaîne complète et indication de bascule.
- Signalement des modifications non appliquées.

## Prochaine validation terrain

- Appel réel sur une campagne pilote avec destination principale + deux secours.
- Laisser sonner la principale jusqu'au timeout, vérifier le secours 1, puis le secours 2.
- Confirmer les événements `calltracker_routing_overflow_triggered` dans les logs.

## Livré 1.11.14
- Multi-sites/domaines par campagne avec ciblage exact du WordPress, y compris sous-répertoires.
- Formulaires groupés par site dans la configuration de campagne.


## Livré localement — LeadTracker AWM 1.11.67 (2026-10-16)
- Une campagne déjà ouverte revient directement à ses leads/export sans navigation réseau. **Résultat attendu :** supprimer le faux « Chargement des campagnes » lors d'un clic sur la campagne courante.