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