← Roadmap publique
Contexte développement
CallTracker AWM V1.10.6Snapshot sécurisé de la version effectivement publiée. Les lignes potentiellement sensibles sont masquées automatiquement.# Contexte développement — CallTracker AWM 1.10.6 --- ## CHANGELOG.md ## 1.10.6 - Refonte UX Google Ads / CPL - 2026-09-21 - Refonte complete de la page **CallTracker AWM -> Google Ads** pour suivre le shell visuel AWM en Light et Dark. - Ajoute un en-tete acquisition/CPL avec etats OAuth, MCC et synchronisation visibles immediatement. - Remplace le rendu WordPress brut des champs par des cartes, champs, boutons, tableaux et etats coherents avec CallTracker. - Ameliore fortement le responsive mobile/tablette, notamment la liste des MCC et les actions. - Aucun changement OAuth, API Google Ads, calcul CPL, table SQL ou historique : correctif UX uniquement. ## 1.10.5 - Interface Google Ads restaurée dans CallTracker - 2026-09-21 - Ajoute une page **CallTracker AWM -> Google Ads** directement depuis le module, sans dépendre de Hub AWM -> Réglages. - Corrige la régression où Hub AWM 4.5.57 masquait l ancien écran `callink-google-ads` alors que le moteur Google Ads 1.10.4 restait actif. - Permet d enregistrer OAuth Client ID / Secret, les deux MCC ou davantage, puis de connecter Google Ads. - Ajoute un test de MCC qui liste les comptes clients accessibles avant toute association de campagne. - Conserve le moteur CPL multi-MCC 1.10.4, l historique, la formule CPL et les synchronisations automatiques. - Le Developer Token historique reste compatible; depuis le 9 septembre 2026, Google rattache l accès API au projet Google Cloud des identifiants OAuth. ## 1.10.4 - Google Ads CPL multi-MCC automatise - 2026-09-21 - Utilise Google Ads API v25 pour recuperer `metrics.cost_micros` par MCC, compte et campagne. - Le Developer Token devient facultatif dans le moteur: si un ancien token existe il reste envoye pour compatibilite, sinon l acces repose sur le projet Google Cloud lie aux identifiants OAuth. - Conserve plusieurs MCC dans une seule integration CallTracker et utilise le bon `login-customer-id` par campagne. - Ajoute la devise Google Ads, le `request-id`, la source et la fraicheur de synchronisation au CPL. - Ajoute une synchronisation automatique par petits lots toutes les 15 minutes pour le mois courant et le mois precedent, sans longue requete bloquante. - Une erreur Google Ads ne remplace jamais un investissement valide par zero; la campagne passe en etat `stale` avec la derniere erreur conservee. - Etend la table CPL de facon additive avec source, devise, statut, date de synchro et metadonnees de source. - Le mode manuel et l historique Laravel restent disponibles sans migration destructive. - Les futurs profils OAuth multiples restent prevus seulement si les deux MCC exigent des identites Google differentes. ## 1.10.3 — Pulse v2 routage — 2026-09-12 - Le score Health CallTracker pénalise uniquement les erreurs de synchronisation/routage connues. - Les campagnes et Twilio restent non modifiés automatiquement; le score sert au triage. ## 1.10.2 — Pulse opérationnel transversal — 2026-09-12 - Expose au Core un pulse campagnes actives / brouillons / erreurs de synchronisation routage. - Le pulse reste strictement descriptif et ne déclenche aucune opération Twilio. ## 1.10.1 — 2026-09-11 - CallTracker respecte désormais le statut opérationnel canonique de CRM AWM. - Un client inactif n'est plus éligible aux opérations CallTracker, tout en conservant campagnes, appels, enregistrements et historique. - La réactivation CRM restaure l'éligibilité selon le réglage CallTracker déjà enregistré. ## 1.10.0 — 2026-09-02 - Structure le parcours client **CallTracker → Nouveaux services → Nouveau funnel → Configuration du numéro → Formulaire/Webhook → Routage**. - Sépare définitivement la commande commerciale de l exécution technique : CRM crée et possède le service Funnel à 10 $/mois; CallTracker prépare la campagne technique. - Un nouveau funnel commence en état **configuration requise** et n active pas la facturation récurrente tant qu aucun numéro n a été acheté et attribué. - L achat du numéro réutilise le service CRM et la campagne préparés, revalide la disponibilité Twilio juste avant la transaction puis active le service CRM après succès. - Un échec Twilio laisse le funnel en configuration pour permettre une nouvelle tentative sans recréer un abonnement; un achat potentiellement accepté mais incomplet est conservé pour vérification afin d éviter un double achat. - Étend le routage modifiable par Hub Client : destination principale, fuseau, horaires, fermetures, destination hors heures, débordement séquentiel, délai et Message 2. - Conserve toutes les validations de propriété côté serveur et journalise séparément les modifications effectuées depuis Hub Client. ## 1.9.9 — 2026-09-02 - Ajoute un webhook HTTPS unique et secret pour chaque Funnel CallTracker. - Active automatiquement la structure de formulaire du funnel après achat du numéro et génère son URL de webhook sans exposer de secret Twilio. - Accepte les envois POST JSON ou formulaire de plateformes externes et reconnaît les champs courants nom, courriel, téléphone, message et URL de page. - Ajoute une protection anti-rejeu courte et un identifiant idempotent lorsque la plateforme fournit `submission_id` ou un identifiant de requête. - Les formulaires reçus sont enregistrés dans l historique CallTracker existant et alimentent immédiatement Leads et CPL du bon funnel. - Ajoute un test client non destructif qui vérifie campagne, jeton et stockage sans créer de faux lead. - Conserve le dernier instant de réception par funnel pour faciliter le diagnostic dans Hub Client. ## 1.9.8 — 2026-09-02 - Ajoute la recherche sécurisée de numéros Twilio pour Hub Client sans exposer les identifiants ni les URL d API. - Permet au client CallTracker autorisé d acheter un numéro et de créer son Funnel directement depuis son Hub. - Chaque achat crée une campagne CallTracker, attribue le numéro et lie un service CRM Funnel à 10 $/mois. - Le service est préparé avant l appel Twilio et supprimé automatiquement si aucun achat externe n a eu lieu. - Si Twilio accepte l achat mais qu une étape locale échoue, la campagne est conservée pour empêcher un double achat et Alliance reçoit un état à vérifier. - L inventaire des numéros est invalidé après achat afin de refléter immédiatement le nouveau numéro. ## 1.9.7 — 2026-09-02 - Livre la phase 1 du **Lot C — Routage avancé**. - Ajoute des horaires hebdomadaires par campagne dans le fuseau déjà géré par CallTracker. - Ajoute les fermetures spéciales / jours fériés au format YYYY-MM-DD. - Ajoute une destination hors heures facultative; si elle est vide, CallTracker ferme proprement l appel au lieu de transférer vers une mauvaise route. - Ajoute une destination de débordement séquentielle après non-réponse, occupé ou échec de la première destination. - Ajoute un délai de sonnerie configurable de 10 à 60 secondes. - Ajoute un aperçu de la route effective dans Hub : état Ouvert/Fermé, heure locale, destination actuelle et débordement. - Ajoute la route Core `callink/v1/routing-next` signée par Twilio pour enchaîner le secours sans sonner deux destinations en parallèle. - Étend Validation et santé : empreinte, horaire, destination hors heures, débordement, délai et tests requis. - Les équipes, priorités, stratégies multi-tentatives, modèles réutilisables et tests simulés restent dans le Lot C phase 2. # Changelog — CallTracker AWM ## 1.9.6 — 2026-08-25 - Ajoute la bascule globale de l’ancienne plateforme dans **Validation et santé**. - Resynchronise par lots tous les numéros des campagnes actives et les numéros encore actifs dans l’export legacy retrouvés localement vers le webhook entrant AWM. - Reprend également les numéros dont les appels entrants sont désactivés et les numéros actifs legacy retrouvés sur une campagne locale maintenant inactive; AWM garde le webhook puis bloque leur transfert. - Refuse la finalisation si un numéro actif de l’export legacy ne correspond à aucune campagne locale, afin de ne jamais laisser un numéro oublié sur l’ancienne plateforme. - Résout les Phone Number SID manquants, retire `VoiceFallbackUrl` et `VoiceApplicationSid`, puis relit Twilio pour confirmer la reprise. - Ajoute progression, aperçu, erreurs par campagne, reprise sans popup et journal Core. - Ajoute le verrou **BASCULE AWM** qui transforme Laravel en référence historique et bloque les nouveaux imports migration/CPL. - Ajoute une réouverture exceptionnelle explicite pour les imports historiques. - Conserve Lot C Routage avancé comme prochaine implémentation et référence l’accès API Google approuvé pour le futur Lot E CPL/Google Ads. --- ## 1.9.5 — 2026-08-25 - Corrige les campagnes existantes dont le numéro de réception a été modifié : la sauvegarde déclenche maintenant une resynchronisation du webhook entrant Twilio vers AWM. - Vérifie le Phone Number SID; s'il manque ou ne correspond plus au numéro de campagne, le SID est recherché dans le compte Twilio configuré puis rattaché à la campagne. - Priorité de destination explicite : numéro de transfert de campagne, puis numéro du client en fallback. - Une modification du numéro client resynchronise automatiquement les campagnes qui utilisent ce fallback et n'ont pas d'override propre. - Ajoute un bloc « Routage entrant Twilio » dans l'éditeur avec destination effective, dernière destination synchronisée, date, erreur éventuelle et bouton de resynchronisation manuelle. - Conserve une empreinte de configuration afin de ne contacter Twilio que lorsqu'un élément critique de routage change. - Journalise les synchronisations et échecs dans Core AWM sans empêcher l'enregistrement local de la campagne. - Exige Core AWM 4.5.43. - Utilise Hub AWM 4.5.15 pour empêcher le Heartbeat WordPress de déclencher le loader plein écran toutes les ~30 secondes dans l’éditeur. ## 1.9.4 — 2026-08-25 - Retire l'autosave WordPress natif de l'éditeur interne `callink_campaign` afin d'éviter le dialogue bloquant « Connexion perdue » et la sauvegarde locale navigateur hors du contrat AWM. - Conserve Heartbeat pour les verrous/session, mais affiche l'état de connexion directement dans la barre **Enregistrer la campagne**. - Affiche **Connexion active**, **Hors ligne — reconnexion automatique** ou **Connexion WordPress instable — enregistrement manuel disponible** sans modal navigateur. - Le bouton d'enregistrement n'est désactivé que lorsque le navigateur est réellement hors ligne; une alerte Heartbeat seule n'empêche pas une tentative manuelle. - Supprime les notices natives `lost-connection` / stockage local lorsqu'elles sont injectées dans l'éditeur de campagne. - Exige Core AWM 4.5.42 et Hub AWM 4.5.14 pour l'expérience complète. - Référence le correctif dans la roadmap sans marquer les validations Twilio terrain comme terminées. --- ## 1.9.3 — 2026-08-25 - Ajoute un registre persistant d idempotence pour les callbacks Twilio de statut et d enregistrement. - Détecte les rejeux et empêche les doubles écritures sans bloquer les retries légitimes des routes TwiML. - Empêche les statuts hors ordre de faire régresser un appel grâce à `SequenceNumber` et aux états monotones. - Ajoute une file de reprise locale courte pour erreurs transitoires, cinq tentatives et un état échec définitif visible dans Validation et santé. - Évite de rejouer les erreurs 4xx déterministes. - Normalise appels et formulaires vers un temps UTC canonique et calcule les périodes CPL dans le fuseau de chaque campagne. - Retire l URL Twilio brute du contrat client et passe la lecture des enregistrements par un proxy sécurisé Core/Hub Client. - Exige Core AWM 4.5.41; l expérience client complète utilise Hub Client AWM 1.8.7. - Met à jour roadmap et documentation sans marquer les validations terrain comme terminées. --- ## 1.9.2 — 2026-08-25 - Ajoute le centre **Validation et santé** accessible depuis Hub AWM. - Compare les compteurs de migration attendus et importés pour clients, campagnes, numéros, appels, formulaires et périodes CPL, en tenant compte des exclusions persistantes. - Analyse les doublons, orphelins et incohérences de propriétaire afin de faire ressortir les exceptions avant clôture. - Ajoute un diagnostic par campagne : client, numéro, SID Twilio, affectation, webhook entrant, destination, fuseau horaire, Message 1, Message 2, Dialer, enregistrement et dernière activité. - Ajoute un parcours de tests guidés pour la configuration, l’appel entrant, la destination, le CPL, le Dialer sortant, l’enregistrement et les messages audio selon les réglages actifs. - Permet d’approuver une campagne seulement après validation explicite; l’approbation est liée à une empreinte SHA-256 des paramètres critiques et devient périmée si ceux-ci changent. - Ferme l’exposition client du CPL par défaut : Core et Hub Client n’affichent que les campagnes approuvées, avec un état **CPL en validation** pour les autres. - Ajoute une clôture de migration signée et réversible après approbation des campagnes actives; la clôture est refusée lorsque des exceptions bloquantes subsistent ou qu’une campagne active reste non approuvée; les campagnes inactives peuvent être revues séparément pour leur CPL historique. - Remplace les confirmations navigateur natives des principaux flux CallTracker actifs par des confirmations AWM intégrées : inventaire de numéros, achats/réservations, campagnes, imports, CPL, Twilio, Google Ads, audio et historique. - Journalise les validations, approbations, réouvertures et clôtures dans Core AWM. - Exige Core AWM 4.5.39, Hub AWM 4.5.13 et Hub Client AWM 1.8.6 pour l’expérience complète. --- ## 1.9.1 — 2026-08-24 - Ajoute un marqueur de résultat explicite pour les opérations natives de campagne : corbeille, restauration, suppression définitive et enregistrement groupé. - Ces résultats sont consommés par le loader AWM au lieu d’un bandeau WordPress. - Le mécanisme reste compatible avec l’action native « Annuler » extraite par Hub lorsque WordPress la fournit. - Aucun changement de tables, métas, routes métier, tombstones, historique ou formule CPL. --- ## 1.9.0 — 2026-08-24 - Corrige définitivement le lien WordPress `Toutes` noir sur noir : `.subsubsub` est stylé directement car WordPress le rend hors de `#posts-filter`. - Ajoute les réglages par campagne **Enregistrer les appels**, **Dialer côté client** et **Fuseau horaire**. - Le fuseau proposé provient uniquement de la fiche CRM/WHMCS; aucune recherche d’adresse externe n’est lancée. - Les appels entrants peuvent demander un enregistrement Twilio conditionnel avec callback Core; les métadonnées d’enregistrement sont synchronisées dans l’historique canonique. - Les appels sortants restent visibles mais strictement exclus des leads et du CPL. - La migration réutilise le réglage historique `record_call` pour initialiser le nouveau réglage sans rupture. ## 1.8.1 — 2026-08-24 - Corrige le listing WordPress des campagnes pour qu’il hérite entièrement des couleurs du shell AWM en clair/sombre. - Rétablit le contraste de « Toutes », filtres, pagination, champs de recherche, tableaux et actions lorsque le thème sombre est changé dynamiquement. - Remplace les fonds noirs opaques du listing par les surfaces partagées Hub/Core sans modifier les campagnes ni leur historique. ## 1.8.0 — 2026-08-24 - Ajoute le routage entrant par campagne avec **Message 1 — Avertissement** puis **Message 2 — Publicité** avant la redirection. - Intègre le MP3 d’avertissement Alliance par défaut; Alliance peut le remplacer ou revenir au fichier par défaut. - Permet au client de téléverser/remplacer/supprimer son Message 2 MP3, de l’activer/désactiver et de modifier son numéro de réception uniquement pour ses campagnes. - Ajoute le contrôle administratif complet des deux messages et de la destination depuis la fiche client Hub AWM. - Stocke les MP3 dans un répertoire privé Alliance, limite à 5 Mo, valide la signature MP3 et les sert par une URL Core signée. - Écrit maintenant les nouveaux appels Twilio entrants et sortants dans `callink_calls` en plus du post type historique; les callbacks mettent à jour statut et durée de façon idempotente. - Les appels sortants apparaissent dans l’historique comme **Sortant** mais restent strictement exclus des leads et du CPL. - Conserve la migration Laravel, les identifiants historiques, les exclusions anti-réimportation et les routes existantes. --- # Changelog — CallTracker AWM ## 1.7.0 — 2026-08-19 - Rafraîchit le lot de migration à partir de l’export Laravel du 19 août 2026. - Intègre 69 306 appels et 44 712 formulaires attribuables; conserve 17 appels et 2 379 formulaires orphelins hors attribution. - Utilise le propriétaire canonique de la campagne comme frontière client pour 25 351 appels dont le `client_id` Laravel historique diffère, tout en conservant cet identifiant pour audit. - Étend l’outil Migration existant aux 3 602 lignes de coûts/CPL et protège les lignes WordPress manuelles. - Signale les erreurs SQL CPL comme résultat partiel plutôt que comme réussite complète. - Refuse l’import CPL vers une campagne non publiée, en corbeille, supprimée ou exclue. - Ajoute le formulaire AWM intégrable par campagne avec défi HMAC, anti-robot, limitation et dédoublonnage. - Ajoute la réception Connector pour Elementor et autres intégrations locales autorisées. - Étend `callink_forms` de manière additive aux identifiants de soumission, sources, téléphone, page et empreintes techniques. - Aligne le nombre de leads sur appels entrants plus formulaires dans l’administration et le portail client. - Conserve le flux courriel historique comme repli et ne prend pas en charge les fichiers dans cette première version. - Exige Core AWM 4.5.8; aucune table, route, option, méta ou identité historique n’est supprimée ou renommée. --- ## Historique des versions précédentes # Changelog — CallTracker AWM ## 1.6.0 — 2026-08-19 ### Ajouté - Service `CallLink_Campaign_Bulk_Actions` pour les aperçus et exécutions groupées de campagnes et réservations locales. - Actions campagne : archivage, corbeille, libération Twilio, suppression définitive et réattribution cliente. - Actions inventaire : réservation locale, réattribution et retrait de réservation. - Aperçu serveur détaillé, phrase de confirmation, jeton à usage unique revendiqué atomiquement, empreinte d’état, verrouillage concurrent, limites de lot et résultats par élément. - API interne d’inventaire partagée par les parcours unitaires et groupés : normalisation, lecture, écriture et retrait de réservation. ### Sécurité et compatibilité - Niveau Core `calltracker/approve`, nonce, validation stricte, confirmation sensible à la casse et journalisation pour chaque lot sensible. - Le client cible d’une réservation est revalidé côté serveur avec la même éligibilité CallTracker que l’interface. - Inventaire Twilio relu directement lors de l’exécution d’un lot de réservations. - Exclusion legacy explicitement persistée pour les mises à la corbeille et suppressions personnalisées. - Appels et formulaires conservés; aucune table, option, route, méta ou identifiant historique renommé ou supprimé. - Le post type historique `callink_campaign` et le statut technique `publish` restent compatibles et non publics. ### Corrigé - Les suppressions par changement direct de statut ne peuvent plus contourner la protection anti-réimportation. - Les actions unitaires et groupées utilisent maintenant la même frontière de validation des réservations. - Une erreur de nettoyage local après une libération Twilio irréversible est signalée et journalisée sans présenter la libération externe comme annulée. - La libération Twilio retire désormais la réservation locale depuis une seule frontière partagée par les parcours unitaires et groupés. - Les lots campagne qui libèrent ou réattribuent un numéro verrouillent aussi la ressource téléphonique afin d’éviter une collision avec un lot de réservations. - Les corbeilles et suppressions destructives échouent de manière fermée si l’exclusion legacy d’une campagne historique ne peut pas être réellement persistée. - Les options partagées de réservations, d’exclusions legacy et d’instantanés de suppression utilisent maintenant des écritures sérialisées avec relecture de persistance. - Après une libération Twilio acceptée, l’état local, les appels entrants, le Dialer et le retrait de réservation sont contrôlés séparément; toute divergence est signalée dans le résultat et le journal Core. - Une réattribution vérifie le propriétaire enregistré, restaure la réservation concurrente si l’écriture principale échoue et compare le nombre d’appels/formulaires réellement propagés. --- ## 1.5.1 — 2026-08-19 - L’éditeur natif `callink_campaign` n’utilise plus le workflow éditorial WordPress : libellés Campagne, boîte Publier retirée et colonne latérale de publication supprimée. - Ajout d’une barre AWM « Enregistrer la campagne »; le statut WordPress `publish` reste uniquement un état technique interne de compatibilité. - Les messages « Article mis à jour » deviennent « Campagne enregistrée » et sont consommés par le loader AWM au lieu d’un bandeau. - La liste Campagnes masque les vues de statuts éditoriaux WordPress et remplace la colonne Publication par « Dernière modification ». - La campagne reste explicitement non publique et non exposée au front-end. ## 1.5.0 — 2026-08-19 - Ajout de l’inventaire Twilio à quatre états : **Libre, Réservé, Attribué, À vérifier**. - Comparaison serveur du compte Twilio Alliance avec toutes les campagnes CallTracker sans exposer les identifiants Twilio au navigateur. - Détection des doublons de numéro, campagnes locales absentes du compte Twilio, réservations orphelines et numéros encore détenus après corbeille/libération déclarée. - Affichage du dernier rattachement connu, de la campagne et du client lorsque disponibles. - Réservation et retrait de réservation protégés par permission CallTracker Modifier, nonce, validation et journal de sécurité Core. - Cache Twilio court et invalidation automatique après achat ou libération d’un numéro. ## 1.4.1 — 2026-08-18 - Le Dialer accepte maintenant une campagne liée à un alias historique sûr du client canonique, via le résolveur d’identité Core 4.5.4. - Les contrôles restent stricts : campagne publiée, statut actif, Dialer activé, numéro Twilio présent et identité cliente reliée de façon sûre. - Les nouveaux appels sortants lancés depuis le Hub Client sont attribués à la fiche canonique portée par la session lorsque la campagne conserve encore un ancien propriétaire technique. ## 1.4.0 — 2026-08-18 - CallTracker AWM 1.4.0 devient la référence officielle du shell visuel AWM partagé. Son ancien en-tête spécifique est remplacé par le shell Core afin d’éviter les doublons tout en conservant toutes les routes et fonctions existantes. ## Sécurité 1.3.7 — 2026-08-17 - CallTracker AWM 1.3.7 utilise le coffre Core 4.4.0 pour protéger au repos les secrets Twilio et Google Ads sans modifier les routes historiques. # Changelog — CallTracker AWM ## 1.3.6 — 2026-08-17 - Les routes REST historiques Twilio `/callink/v1/token`, `/voice`, `/incoming` et `/status` sont désormais enregistrées exclusivement par Core AWM 4.3.9. - CallTracker conserve le traitement métier Twilio mais n’est plus propriétaire de la surface API publique. - Les URL historiques restent strictement inchangées. ## 1.3.5 — 2026-08-17 - Les campagnes historiques mises à la corbeille ou supprimées définitivement sont maintenant inscrites dans une liste d’exclusion persistante (`callink_legacy_campaign_tombstones`). - Les synchronisations/migrations depuis l’ancienne plateforme ignorent systématiquement ces campagnes et ne peuvent plus les republier ni les recréer automatiquement. - Une campagne déjà présente dans la corbeille au moment d’une synchronisation est automatiquement protégée contre la résurrection. - Une restauration WordPress explicite retire l’exclusion et autorise de nouveau la synchronisation de cette campagne. - Les exclusions et restaurations sont consignées dans le journal de sécurité Core lorsqu’il est disponible. ## 1.3.4 — 2026-08-17 - Correctif global des associations historiques Clients ↔ Campagnes : les campagnes liées à une ancienne adresse du même client sont maintenant visibles dans la fiche CallTracker canonique lorsqu’une correspondance sûre peut être établie. - Exemple couvert : une campagne liée à `info@domaine.tld` et une fiche WHMCS liée à `proprietaire@domaine.tld`, avec identité cohérente. - Aucun rattachement n’est réécrit silencieusement; les consolidations permanentes restent soumises au rapprochement global contrôlé. ## 1.3.3 — 2026-08-17 - Rapprochement global de l’ensemble des anciennes fiches CallTracker vers les fiches WHMCS canoniques, avec fusion en lot limitée aux correspondances sûres et uniques. - Les campagnes, appels et formulaires suivent la fiche canonique après rapprochement; les cas ambigus restent visibles pour validation manuelle. - Correction du rendu réel des écrans WordPress de campagnes : retrait du logo historique dupliqué et conservation d’un seul en-tête CallTracker en haut. - Harmonisation complète du listing et de l’éditeur Campagnes en clair/sombre, incluant champs, metaboxes, publication, tableaux et actions. - Compatibilité des associations clients historiques : les campagnes liées par ID WHMCS ou courriel sûr apparaissent dans la fiche CRM/WHMCS canonique. - Agrégation des compteurs de campagnes, appels et formulaires sur les références sûres du même client. ## 1.3.2 — 2026-08-17 - Amélioration du parcours Campagnes : visualisation consolidée des appels et formulaires par campagne. - Campagnes associées visibles depuis la fiche client avec compteurs et accès direct à l’activité. - Harmonisation visuelle de l’administration Campagnes et en-tête CallTracker avec le thème AWM. ## 1.3.1 — 2026-08-17 - Activation ou désactivation d’un client pour CallTracker sans modifier son statut WHMCS/CRM. - Les clients CallTracker actifs sont les seuls proposés lors de la création d’une campagne avec achat Twilio. - Rattachement direct d’une campagne existante non assignée depuis l’écran Clients. - Préselection du client lors de l’ouverture de « Nouvelle campagne ». - Refus serveur d’un achat ou d’un jeton Dialer client lorsque CallTracker est désactivé pour ce client. - Compatibilité préservée pour les clients ayant déjà des campagnes historiques. ## 1.3.0 — 2026-08-17 - Ajout d’un accès Clients directement dans CallTracker AWM. - Recherche des clients par nom, entreprise, courriel, téléphone, campagne ou numéro Twilio. - Filtres Actifs, Inactifs et Tous disponibles depuis CallTracker; les clients inactifs restent masqués par défaut. - La référence WHMCS demeure la source du statut actif, avec respect des exceptions manuelles et de la fiche interne Alliance Web Marketing. - Réutilisation de la route historique `callink-clients` et des métadonnées existantes, sans nouvelle table ni duplication de clients. # Historique — CallTracker AWM ## 1.2.0 — 2026-08-17 - Contrat de permissions Core AWM 1.0 appliqué aux campagnes, numéros, historique et CPL. - Niveaux distincts pour consultation, opérations quotidiennes, approbation et réglages. - Signatures Twilio refusées consignées dans le journal central avec limitation anti-bruit. - Diagnostic Core des webhooks Twilio et du Dialer. - Activation arrêtée proprement avec Core antérieur à 4.3.0, sans modification des campagnes ni de l’historique. ## 1.1.2 — 2026-08-15 - Libération explicite d’un numéro Twilio sans recopie manuelle. - Comparaison serveur du numéro enregistré avant l’appel irréversible à Twilio. --- ## README.md ## 1.10.6 - Interface Google Ads professionnelle La page **CallTracker AWM -> Google Ads** suit maintenant le shell AWM : cartes Light/Dark, etats OAuth/MCC/synchronisation, formulaires compacts et rendu responsive. Le moteur Google Ads/CPL 1.10.4/1.10.5 reste inchangé. ## Google Ads - écran de configuration 1.10.5 CallTracker possède maintenant sa propre page **CallTracker AWM -> Google Ads**. Les réglages Google Ads ne sont plus recherchés dans **Hub AWM -> Réglages**. La page permet d enregistrer OAuth, plusieurs MCC, de connecter Google, de tester un MCC et d ouvrir directement les campagnes / l historique CPL. ## Google Ads CPL - 1.10.4 CallTracker peut utiliser deux MCC ou davantage avec une seule integration Google Ads. Chaque campagne conserve son MCC (`login_customer_id`), son compte Google Ads et, au besoin, son `campaign_id`. Le cout mensuel provient de `metrics.cost_micros` et alimente l investissement CPL sans modifier la definition des leads: appels entrants admissibles + formulaires admissibles. La synchronisation automatique traite de petits lots toutes les 15 minutes et reprend le mois courant ainsi que le mois precedent. Une erreur API ne remplace jamais un cout valide par zero. La derniere valeur reste disponible avec un etat de fraicheur et la derniere erreur pour diagnostic. Depuis septembre 2026, le niveau d acces Google Ads API est lie au projet Google Cloud qui porte les identifiants OAuth. Le champ Developer Token historique est donc facultatif dans le moteur; une valeur deja enregistree reste envoyee pour compatibilite. ## 1.10.3 — Pulse v2 routage — 2026-09-12 - Le score Health CallTracker pénalise uniquement les erreurs de synchronisation/routage connues. - Les campagnes et Twilio restent non modifiés automatiquement; le score sert au triage. ## 1.10.2 — Pulse opérationnel transversal — 2026-09-12 - Expose au Core un pulse campagnes actives / brouillons / erreurs de synchronisation routage. - Le pulse reste strictement descriptif et ne déclenche aucune opération Twilio. # CallTracker AWM 1.10.0 — parcours Funnel client piloté par CRM CallTracker 1.10.0 sépare maintenant la commande du service et l exécution téléphonique. Le client démarre dans **Nouveaux services**, crée un Funnel à **10 $/mois** géré commercialement par CRM, choisit ensuite son numéro, récupère son webhook de formulaire puis configure son routage avancé. Le service CRM reste en configuration et non facturable automatiquement jusqu à l attribution confirmée du numéro. Le routage client couvre la destination principale, le fuseau, les horaires, les jours fermés, la destination hors heures, le débordement séquentiel et le délai. Les secrets et opérations Twilio restent exclusivement côté Alliance/Core/CallTracker. # CallTracker AWM 1.9.9 — Webhooks de formulaires par Funnel CallTracker 1.9.9 fournit à chaque Funnel client un webhook HTTPS unique. Les envois provenant d Elementor, Gravity Forms, WPForms ou d un formulaire personnalisé sont attribués automatiquement au bon client et à la bonne campagne, puis stockés dans l historique de formulaires utilisé par Leads et CPL. ## Routage avancé 1.9.7 La phase 1 du Lot C ajoute des horaires par campagne, des fermetures spéciales, une destination hors heures et un débordement séquentiel. Le fuseau de campagne demeure la référence. Le secours est déclenché par une route TwiML Core signée par Twilio et ne sonne qu après échec/non-réponse de la destination initiale. Hub affiche l aperçu de la route; Validation et santé exige les essais correspondants. CallTracker AWM 1.9.6 ajoute une procédure contrôlée pour reprendre **tous les numéros des campagnes actives et les numéros encore actifs dans l’export legacy retrouvés localement** dans AWM avant de décommissionner l’ancienne plateforme. La procédure est accessible dans **Validation et santé** et travaille par lots avec progression. La reprise ne se contente pas de modifier WordPress : elle résout le Phone Number SID si nécessaire, replace le `VoiceUrl` Twilio sur AWM, retire les fallbacks/application voix legacy et relit ensuite la ressource Twilio pour confirmer que la bascule a réellement eu lieu. Les campagnes dont les appels entrants sont désactivés sont quand même reprises par AWM; le webhook CallTracker refuse ensuite le transfert, ce qui rend enfin le crochet de désactivation maître du comportement. Une fois tous les numéros conformes, l’action **BASCULE AWM** verrouille les imports Laravel et CPL. L’ancienne plateforme reste consultable comme référence historique mais ne peut plus réécrire les données CallTracker sans réouverture explicite. # CallTracker AWM 1.9.5 — resynchronisation du routage des campagnes existantes CallTracker 1.9.5 corrige le cas des campagnes déjà existantes lorsque le numéro de réception est modifié. La sauvegarde locale ne suffit plus : CallTracker vérifie le Phone Number SID, reprend automatiquement le webhook entrant AWM chez Twilio et mémorise la destination effectivement synchronisée. Un état de routage et une action de resynchronisation manuelle sont visibles dans l'éditeur de campagne. Le routage reste dynamique : le numéro de transfert défini dans la campagne est prioritaire; s'il est vide, le numéro de destination du client est utilisé. Une modification du numéro client resynchronise aussi les campagnes qui utilisent ce fallback. Les lots Validation et santé, Fiabilité 1.9.3 et connexion non bloquante 1.9.4 restent conservés. Pour l’éditeur complet, Hub AWM 4.5.15 filtre aussi les requêtes Heartbeat de fond afin qu’elles n’ouvrent plus le loader « Récupération des données » toutes les ~30 secondes. --- # CallTracker AWM 1.9.4 — éditeur de campagne sans popup WordPress CallTracker 1.9.4 corrige le dialogue WordPress « Connexion perdue » sur les campagnes. L'autosave WordPress est retiré uniquement du CPT interne CallTracker; la barre AWM conserve l'enregistrement manuel et affiche un état de connexion non bloquant. Le lot Fiabilité 1.9.3 reste inchangé et continue sa validation terrain. # CallTracker AWM 1.9.3 — Fiabilité des événements Twilio CallTracker 1.9.3 consolide le lot Fiabilité et sécurité des événements après le centre Validation et santé de 1.9.2. ## Webhooks - idempotence persistante pour `status` et `recording`; - détection de rejeu/doublon; - ordre monotone des statuts avec `SequenceNumber`; - file de reprise locale pour erreurs transitoires; - cinq tentatives maximum puis échec définitif visible; - erreurs 4xx déterministes ignorées sans boucle de retry; - événements TwiML observés pour rejeu mais jamais bloqués uniquement parce qu ils sont répétés. ## Temps et CPL Les nouveaux appels/formulaires disposent d instants UTC canoniques. Les historiques sont convertis avec le fuseau de leur campagne lorsque possible. Le CPL mensuel utilise le mois civil du fuseau de campagne puis convertit ses bornes en UTC pour interroger les données. ## Enregistrements L API cliente ne retourne plus l URL Twilio brute. Core vérifie la propriété, récupère le média côté serveur avec les secrets protégés, puis Hub Client le relaie via une URL locale de session. ## Validation et santé Le panneau affiche les événements reçus, traités, en reprise, en échec définitif et le dernier événement UTC. Les tests réels Alliance/Twilio restent obligatoires avant approbation des campagnes et clôture de migration. --- ## ROADMAP.md # 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.