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