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