Du dashboard au téléphone réel

Les 157 tests ciblés de six fichiers passent. Quatre tests rendant le vrai éditeur échouaient avant la correction, sur les plages fractionnées, le fuseau Londres et une semaine vide. Les premiers contrôles visuels en français, néerlandais et anglais, à 390 et 1440 pixels, n’ont détecté aucun défaut sur les écrans examinés.

Les 12 scénarios navigateur passent sans scénario ignoré ni nouvelle tentative. La recette utilise une base neuve et les vraies API de prévisualisation, de commande et d’enregistrement. La relecture confirme les six calendriers attendus, les six commandes confirmées et la conservation des politiques de repli et des propriétaires. Le menu de référence reste inchangé, aucune ligne d’appel n’est créée et tous les processus du banc sont arrêtés. Aucun PBX ni appel externe n’est lancé.

168 tests ciblés et six scénarios navigateur passent. Les parcours couvrent le français, le néerlandais et l’anglais, à 390 et 1440 pixels, sans scénario ignoré ni nouvelle tentative. Les 18 captures conservent la taille réelle du navigateur ; les contrôles exécutés ne détectent ni débordement horizontal ni violation d’accessibilité.

La recette utilise des files synthétiques, une base neuve et les API réelles de prévisualisation, de commande et d’enregistrement. La relecture confirme 36 commandes acquittées, 18 audits de modification des horaires et 18 calendriers conservés avec leurs octets et métadonnées d’origine. Les membres, les politiques de repli, les délais de post-appel et les menus vocaux de référence restent inchangés. Aucune ligne d’appel n’est créée dans les organisations de recette ; tous les processus du banc sont arrêtés.

Le frontal natif passe 18 contrôles locaux. Caddy 2.11.7 sert réellement HTTPS et transmet des trames WebSocket avec le sous-protocole attendu. Les chemins de contrôle, les origines étrangères et les certificats amont incorrects sont refusés ; une nouvelle connexion fonctionne après reprise de l’amont. La recette utilise une base neuve, des certificats temporaires et des services simulés sur la boucle locale. Quatre échecs provoqués vérifient aussi le refus du résultat et le nettoyage. Le binaire macOS, les ports et la confiance TLS de test ne qualifient ni l’image du serveur Linux ni le réseau public. Aucun navigateur, SIP, média ou appel opérateur n’est exercé.

La mise à jour de sécurité passe 772 tests ciblés dans 25 fichiers, le typage de la construction Linux, ESLint et l’audit de traduction. Next.js et sa configuration de lint sont alignés sur 16.3.8. Le traitement natif des images reste disponible après retrait des dépendances de développement et produit un AVIF dans le conteneur Linux. Le contrôle du contexte Docker conserve 11 sources attendues et exclut 43 fichiers privés synthétiques.

La recette navigateur confirme la reprise de session sans changement des données, l’indépendance de deux connexions et la révocation après déconnexion. Le banc distingue désormais une requête de synchronisation explicitement annulée avant réponse d’une réponse reçue : une réponse réussie, corrélée et sans commande reste obligatoire. Les six scénarios Twilio simulés sont rejoués dans les trois langues et deux largeurs ; 12 contrôles d’accessibilité et 18 contrôles de largeur passent. Aucun appel réel n’est démontré.

La correction du paquet passe 213 tests ciblés dans quatre fichiers. Elle vérifie le vrai chargeur de configuration de production et les réglages requis, sans démarrer le moteur téléphonique. Le constructeur Docker exclut 39 fichiers synthétiques privés tout en conservant les sources attendues. Le lanceur laptop copie la police locale ; six rendus de connexion FR/NL/EN chargent cette police, sans débordement ni violation d’accessibilité. Ces contrôles du lot précédent restent distincts de la nouvelle recette Linux et ne prouvent aucun appel réel.

La nouvelle image démarre en lecture seule, sous un compte non privilégié, sans accès réseau ni dossier du Mac monté. Les 85 migrations passent sur une base neuve jetable ; aucune incohérence de clé étrangère n’est détectée. Les pages de connexion dans les trois langues, la police et sa licence sont servies ; une API protégée refuse l’accès anonyme. Piper et FFmpeg produisent un fichier MP3 contrôlé pour chaque langue. Aucun son n’est joué ni transmis à un téléphone. Le premier banc a échoué car il cherchait la police uniquement dans le HTML et interprétait mal le message de suppression Docker ; ces échecs sont conservés, puis le banc corrigé vérifie aussi les feuilles de style. Le conteneur d’essai est supprimé après les contrôles. Cette preuve historique précède la mise à jour de sécurité décrite ci-dessous.

La campagne précédente de l’assemblage hors ligne passait 325 tests dans 11 fichiers, dont 28 pour le préparateur. Les réglages générés sont confrontés aux contrats du combiné, du contrôleur et du matérialiseur d’appareils. La commande est exercée sur une base neuve ; elle ne promeut pas l’inventaire et ne remplace pas une installation existante. TypeScript, ESLint et l’audit de traduction passent. Le frontal est aussi interprété par Caddy 2.11.7 et le bundle par Docker Compose 5.2.0, sans démarrer de serveur ni contacter le démon Docker. Le cache web est privé et inscriptible par son compte d’exécution ; HTTPS Asterisk refuse explicitement TLS 1.0 et 1.1. Ces contrôles ne prouvent pas le démarrage, les certificats ni l’audio. Aucun conteneur téléphonique ni appel réel n’est lancé.

La campagne de régression passe 1 833 tests dans 60 fichiers complets, sans test ignoré. Le dernier ajustement du titre du combiné est ensuite vérifié par les 146 tests de sa suite, incluant trois nouveaux cas. TypeScript, ESLint et l’audit de traduction passent. Le test serveur compose le vrai contrôleur, son registre et son journal sur base neuve avant l’admission navigateur ; le transport téléphonique reste simulé. Il couvre aussi un décalage de l’horloge PBX sans prolonger la sonnerie.

Les six scénarios navigateur FR/NL/EN passent à 390 et 1440 pixels. Les 18 captures sont relues et les 12 contrôles d’accessibilité du combiné passent. La réponse exige un clic et une seconde admission ; une offre retirée ne déclenche pas le micro. Ces scénarios utilisent le navigateur et le client SIP livrés, mais simulent les API d’autorisation, les échanges SIP et le média. Ils ne prouvent ni une inscription SIP réelle, ni l’audio, ni le parcours complet sur un PBX.

Ce laboratoire direct accepte uniquement les appareils V1 hors cellule, avec une génération active unique, un propriétaire cohérent et aucune modification inachevée. Le parcours V2 et les cellules souveraines conservent leurs contrôles propres. Les relectures ne forment pas une transaction atomique avec le serveur téléphonique et ne garantissent pas l’arrêt immédiat d’un média déjà établi. Ce lot ne livre pas un nouveau moteur de menus vocaux ou de files d’attente.

La recette prépare son appareil par le vrai parcours de création, avec un reçu durable qui indique encore une intervention manuelle. Elle compare chaque migration aux sources courantes et contrôle le reçu de l’appareil après restauration. La lecture de vérification ne peut plus réécrire une base refusée.

La campagne précédente de 48 scénarios de restauration du commit 69a231e passait au schéma 85. Les 42 scénarios antérieurs étaient conservés et six couvraient les données privées du compte applicatif. Les archives claires et chiffrées retrouvaient les 85 migrations exactes, les données métier et le reçu de l’appareil. Les 272 tests ciblés, le typage et les contrôles de code passaient aussi.

La restauration conserve maintenant les demandes d’appareils au schéma 86. Les 15 scénarios du profil Twilio et les 48 scénarios du laboratoire de reprise passent sur les sources courantes. Une vraie création V1 terminée est enregistrée avant sauvegarde ; une seconde création réalisée ensuite disparaît lors de la restauration. Le contrôle compare tous les champs de la demande, les appareils, leurs accès, les reçus, les verrous et l’audit. La relecture du même identifiant restitue seulement son état, sans nouvelle opération ni remise du secret. La recette de reprise compare aussi les octets de la base avant et après cette relecture. Les 229 tests ciblés passent dans sept fichiers ; cinq contrôles ciblés de la politique de restauration passent séparément. Les autres cas de cette dernière suite sont hors de cette sélection. Après correction du chargement du banc natif, les 90 tests de l’import sont rejoués avec succès. La première campagne native et son échec restent conservés ; une nouvelle image porte la recette corrigée.

Vérifié sur Linux : restaurer une demande d’appareil interrompue. Une campagne complémentaire de 15 scénarios passe pour les états en attente, incertain et enregistré avant clôture. Le vrai service produit ces trois états ; le processus en attente est interrompu après son premier enregistrement. Les sauvegardes claire et chiffrée retrouvent exactement les dix tables contrôlées, dont les 23 champs de chaque demande, les accès, les reçus, les verrous et l’audit.

Relire une demande restaurée rend uniquement son état, sans nouvel effet ni remise du mot de passe. Une reprise exclusive retrouve les opérations déjà enregistrées et clôt les réservations sans effet. Une opération incertaine conserve son blocage tant que la vérification du runtime manque ; une identité de verrou différente est refusée. Après la vérification simulée du verrou exact, une nouvelle action explicite devient possible.

Les 155 tests ciblés passent dans quatre fichiers, ainsi que les contrôles de code. Le nettoyage du laboratoire est confirmé et sa VM est arrêtée. L’image historique est réutilisée après vérification de ses 306 fichiers backend contre les sources courantes ; aucune nouvelle image complète de l’interface n’est qualifiée. Le runtime téléphonique reste simulé : cette preuve ne valide ni Asterisk réel, ni SIP, ni l’audio, ni la production client.

La sauvegarde et la reprise respectent les permissions privées. La recette vérifie des écritures réellement présentes dans le journal SQLite, des enregistrements placés dans des sous-dossiers privés, puis la lecture et l’écriture par le compte applicatif. Elle compare les propriétaires, permissions et contenus sur le volume Linux, y compris après un échec de restauration et une reprise interrompue. Un autre compte reste sans accès.

Les opérations contrôlent leurs droits avant de démarrer. Un journal de récupération fabriqué par le compte applicatif, ou dont les permissions sont trop ouvertes, est refusé sans modifier les données ni publier un reçu. Une ancienne preuve de préparation ne peut toujours pas autoriser une nouvelle tentative avant ses vérifications.

Les conteneurs Linux amd64 sont exercés sous QEMU sur le laptop, avec des bases jetables et sans réseau applicatif. La campagne confirme le retrait des conteneurs, volumes, images et programmes propres aux essais. La validation CI accepte le rapport réel et refuse 21 rapports volontairement altérés, notamment les preuves incorrectes de permissions, de journal SQLite et de refus de récupération.

Le profil Twilio reste relié au parcours de sauvegarde et restauration. L’import hors ligne crée un volume nommé avec navy.db, lié à une instance et à un profil installé immuable. Un volume existant, une source altérée, des droits incorrects ou une preuve de fin d’import modifiée sont refusés. Les quinze scénarios de la nouvelle recette Linux passent : installation réelle, import, permissions privées, montages TLS, admission des trois rôles, création durable d’une demande V1, sauvegardes claire et chiffrée, restauration et nettoyage des ressources possédées.

La campagne précédente vérifiait aussi deux interruptions réelles de l’import. Un arrêt avant modification et un arrêt après création du volume conservent le verrou de maintenance, refusent les trois rôles et ne publient aucun reçu de fin. La source reste inchangée ; le second essai conserve aussi les données partielles jusqu’au nettoyage contrôlé. Les trois campagnes historiques confirment l’absence de processus, conteneurs et volumes propres aux essais après nettoyage.

La recette utilise l’application et les utilitaires Asterisk amd64 sous Rosetta, avec les outils de reprise ARM64 natifs dans une VM isolée du laptop. Les fichiers TLS sont synthétiques. La copie hors site, la gestion des clés réelles, la planification, le redémarrage téléphonique, les certificats et la reprise d’un appel réel restent à qualifier sur l’hôte retenu, avec son profil dédié ou partagé.

Le déploiement V3 utilise shared-linux-nginx-public-ipv4, avec une IPv4 publique directement portée par Linux. Les champs webPort et edgeTlsPort désignent deux ports distincts en boucle locale. Le profil V2 dédié reste disponible. Le reçu V3 lie exactement 17 fichiers préparés ; la copie publiée contient 21 fichiers dans les mêmes sept répertoires, avec les permissions privées et les propriétaires contrôlés.

Le vhost utilise les listeners nginx génériques 80 et 443 ssl, sans directive default_server ni écoute liée à une IPv4 distincte. Il doit être inséré après les serveurs par défaut existants, dont la sélection reste à vérifier. Ses chemins de certificats et de confiance sont fixes sous la copie publiée du déploiement. Nginx valide le certificat de Caddy, fixe Host et le protocole transmis, reconstruit l’adresse cliente et conserve l’Origin réelle. Caddy fait confiance au seul proxy local, reste privé et conserve les restrictions sur /ws et /ari.

Compose plafonne le web à 1 CPU, 1 Gio et 256 processus ; le contrôleur à 0,5 CPU, 512 Mio et 128 processus ; Asterisk à 1 CPU, 512 Mio et 128 processus ; Caddy à 0,25 CPU, 128 Mio et 64 processus. Ces plafonds ne réservent pas de ressources et ne qualifient aucun nombre d’appels simultanés.

La recette dispose d’un adaptateur d’inspection pour les anciennes API de Docker 24 : il lie la plateforme et l’identifiant exact de l’image à son empreinte de registre, sans téléchargement ni mise à jour de Docker. Ce code ne prouve pas encore une exécution native sur le droplet. Le bundle demande le plugin Docker Compose 2 ou une version compatible plus récente ; l’ancien docker-compose 1.25 ne suffit pas. Le plugin compatible reste à préparer et qualifier séparément, en préservant les outils des autres applications.

214 tests ciblés et six parcours navigateur réussis. La passe finale couvre le français, le néerlandais et l’anglais à 390 et 1440 pixels, sans nouvelle tentative ni scénario ignoré. Douze contrôles d’accessibilité passent sans violation. La relecture de la base confirme les six retraits prévus, les 36 autres opérateurs inchangés et l’absence d’appel créé.

La recette couvre les états admis, expiré, absent ou incohérent, la séparation des organisations et les accès administrateurs. Les parcours navigateur vérifient l’expiration et le retrait explicite, y compris une réponse perdue après l’enregistrement réel.

Les qualifications du banc sont des données synthétiques dans une base neuve. Aucun dossier fournisseur n’est signé ou importé par cette recette, aucun appel ni raccordement opérateur n’est exécuté. Ce lot ne change aucun schéma et ne migre aucune base conservée.

Une demande explicite peut provoquer une seule tentative auprès du fournisseur. Relire la même demande ne renvoie pas d’email. Les renvois sont espacés d’au moins une minute et limités à trois admissions par tranche de quinze minutes pour le même membre ; l’email initial de création reste séparé de ce compteur.

Recette du 8 octobre : 738 tests ciblés et six parcours navigateur réussis. Les parcours FR/NL/EN sur mobile et ordinateur produisent six activations. Les onze reçus restent consultables après un redémarrage, sans nouveau renvoi. Douze contrôles d’accessibilité automatisés passent sans violation. La navigation après activation et les redirections des profils support et opérateur sont vérifiées avec leurs vraies sessions.

La recette utilise des comptes synthétiques, une base neuve et un fournisseur HTTP local. Elle ne crée aucun poste supplémentaire ni élévation de support lors du renvoi. Les bases conservées du laptop ne sont pas migrées pour ces essais.

Chaque modification V1 possède maintenant son identité durable. Après une coupure ou un rechargement, les changements récents permettent de retrouver l’appareil exact, l’action et son état. Création, renouvellement et révocation ne sont pas déduits d’un nom ressemblant dans le registre. Les demandes non résolues sont affichées en premier et bloquent de nouvelles modifications V1 par le même administrateur dans son organisation.

Une lecture ou le renvoi de la même demande ne répète pas son exécution et ne remet aucun secret. Le mot de passe perdu reste irrécupérable ; obtenir un nouvel accès demande un renouvellement explicite de l’appareil identifié. Le dashboard vérifie la génération courante avant de confirmer un renouvellement ou une révocation.

En cours, incertain, enregistré et terminé restent des états distincts. Une opération interrompue exige une reprise d’exploitation après l’arrêt confirmé des processus qui peuvent modifier les appareils. La clôture d’une incertitude ne prouve pas que l’action initiale a réussi. Le registre et la propagation doivent toujours être relus séparément.

Le contrat HTTP exige un identifiant UUID v4 et, pour un appareil existant, la génération attendue. La migration 0085 ajoute ce suivi aux nouvelles bases de test. Une base sans ce suivi refuse les écritures V1 concernées ; le parcours V2 conserve sa remise de secret distincte. Les bases conservées du laptop ne sont pas migrées par cette recette.

La recette comprend des modifications réellement enregistrées dans une base jetable, suivies de la suppression complète de leur réponse HTTP. Elle vérifie la reprise par identifiant, le refus d’un contenu différent et l’absence de second effet ou de nouvelle remise du secret. Les transports téléphoniques restent simulés ; aucune qualification Twilio, inscription SIP ou preuve audio n’en découle.

Les 802 tests ciblés passent dans 23 fichiers. Les 89 scénarios navigateur passent après correction de trois fixtures de test et d’un sélecteur ; les échecs initiaux restent conservés. Les parcours de reprise couvrent FR/NL/EN à 320 et 1440 pixels, avec six captures relues. Une recette complémentaire exerce 13 scénarios HTTP sur une instance réelle et une base neuve : limites de taille, expiration, session révoquée, connexion interrompue, création, renouvellement et révocation. Les trois demandes terminées sont relues dans la base, sans appel ni verrou restant. Tous les processus de cette recette sont arrêtés.

Dans le parcours direct V1, les demandes d’ajout, de renouvellement et de révocation doivent être complètes et lisibles avant de lancer l’opération. Le serveur relit ensuite la session et les droits. Après une perte de réponse, l’administrateur retrouve désormais la demande exacte dans les changements récents : une opération déjà lancée peut avoir été enregistrée.

La réception du corps JSON est limitée à 8 Kio (8 192 octets), 8 192 fragments de lecture et deux secondes au total, sans prolongation à chaque fragment. Ce délai concerne uniquement la lecture du corps, pas l’authentification ni l’écriture. Le décodage UTF-8 est strict, les corps compressés sont refusés et Content-Length reste facultatif mais doit être exact lorsqu’il est présent.

Le contrôle après réception doit retrouver les mêmes utilisateur, organisation, rôle, session et version d’authentification (id, orgId, role, sessionId, tv). Une interruption détectée avant le lancement bloque celui-ci. Une fois l’opération lancée, le traitement d’écriture existant va à son terme, sans annulation ni rejeu automatique ajoutés par ce contrôle. Ce contrôle de réception reste distinct du nouveau suivi durable décrit ci-dessus.

Les 159 tests ciblés de cinq fichiers et les 13 scénarios HTTP avec les vraies API passent sur une instance neuve et isolée. TypeScript, ESLint et l’audit i18n complet passent également. Le cycle manuel V1 ajout, renouvellement et révocation reste fonctionnel ; les cas couvrent aussi les limites du corps, les données invalides, le délai total, une session révoquée avant la fin de réception et des connexions abandonnées avant la fin d’une demande. Le scénario de session prouve le refus après révocation, sans prétendre observer l’instant du premier contrôle d’accès.

Après l’arrêt vérifié de tous les processus de la recette, la lecture SQL seule retrouve un appareil révoqué, deux générations de secret retirées, trois reçus manuels, trois événements d’audit, aucun appel et aucun verrou d’opération restant. Ces preuves concernent la réception HTTP et le registre. Elles ne qualifient ni l’inscription SIP, ni l’audio, ni un téléphone réel ou un opérateur. Aucun PBX n’a été lancé.

/infrastructure/telephony/device-catalog projette en lecture seule la même matrice DEVICE_MODELS que les règles de provisioning. Ses filtres et fiches ne contactent ni l’API devices ni Asterisk. /api/telephony/devices expose une lecture et les actions create, rotate, revoke. Le contrat serveur restitue le modelId, les postes attribuables et leur capacité restante, les limites de configuration et la disponibilité d’une observation. La liste ne sonde pas le serveur téléphonique. /settings projette uniquement les appareils de la personne connectée. Le centre /admin/devices expose ces opérations en français, néerlandais et anglais. Les droits et les politiques de configuration sont vérifiés avant les actions ; une ancienne base sans les preuves requises garde uniquement la lecture. Le mot de passe apparaît une seule fois, sans stockage navigateur ni impression. Une réponse perdue ne provoque aucune répétition automatique ; le registre et les preuves restent relisibles avant toute nouvelle décision.

GET /api/telephony/devices/[publicId]/observation lit sur demande un seul endpoint PJSIP, après contrôle du rôle et de l’organisation. Il restitue la source, l’heure, l’état Asterisk et le nombre de canaux, mais aucun identifiant de canal. Une mutation en cours, une réponse invalide ou un changement du registre donnent un résultat indisponible. Même online ne prouve ni l’audio, ni le routage, ni un appel de bout en bout.

GET /api/telephony/devices/[publicId]/propagation relit sans réseau le reçu durable du protocole v2 ou d’une nouvelle mutation legacy et le corrèle à la génération active. Une opération ou barrière en cours reste visible séparément. Le résultat legacy distingue application vérifiée, intervention manuelle et révocation incertaine. Une application manuelle n’est jamais verte par déduction. Les anciennes lignes ne sont pas requalifiées. La réponse ne contient ni secret, ni identifiant interne, ni empreinte de preuve. Elle enregistre un fait passé, mais ne prouve ni la connexion actuelle, ni un appel.

La migration 0043 rend les reçus legacy append-only et les exige dans la même transaction que le registre. Si cette migration manque, l’écriture échoue avant toute prise de barrière et avant tout appel Asterisk. L’heure d’application est capturée après le retour runtime et ne peut pas précéder la dernière transition de la barrière. Une révocation d’abord incertaine conserve ce reçu, puis la récupération exclusive réapplique la révocation avant d’ajouter une preuve vérifiée, sans effacer l’historique. Les exemptions v2 exigent l’opération, la cible, la phase et la barrière exactes ; elles ne s’appliquent jamais à un secret v1.

Lecture seule obligatoire sur une base ancienne : la liste projette maintenant la disponibilité du ledger 0043. Si cette preuve de migration ne peut pas être lue, création, rotation et révocation sont toutes refusées avec un motif stable. Le centre désactive les actions avant l’écriture. La base historique du laptop n’a pas été migrée ou remise à zéro pendant cette revue ; l’instance courante utilise désormais une base neuve distincte.

La configuration distingue application manuelle, automatique WebRTC, automatique WebRTC et SIP matériel, puis indisponibilité. La capacité de lecture ARI est indépendante de l’autorisation d’écrire les accès. Une rotation ou une révocation doit distinguer identité, état du PBX et sessions en cours. L’écran ne doit pas transformer un effet partiel en réussite globale.

Profil matériel explicite : le parcours direct peut conserver le modèle et appliquer SIP TLS avec SDES-SRTP et Digest SHA-256. Il vérifie le transport déclaré avant de retirer une configuration existante, puis relit les objets appliqués. Le dashboard affiche les paramètres publics du profil sans les présenter comme une connexion réussie. Un profil absent ou invalide ferme cette capacité ; la révocation reste indépendante. Le protocole durable V2 conserve désormais ce profil par génération et le vérifie dans les commandes, reprises, reçus du broker et observations. Une ancienne génération physique sans cette ancre reste refusée. Le dashboard expose les offres et paramètres par système ; une politique modifiée retire la préparation et la remise du secret. Aucun téléphone n’est qualifié par cette seule validation logicielle.

Migrer progressivement les anciens appareils : après un gel explicite des écritures V1, une campagne privée prouve la cellule source de chaque appareil. Le dashboard conserve titulaire, poste et modèle, renouvelle les accès à la génération suivante et demande une reconfiguration manuelle. Un appareil peut passer en V2 tandis qu'un autre reste en V1 ; la réconciliation contrôle séparément les deux preuves. La bascule globale reste une action explicite après la dernière migration. Le parcours logiciel est testé avec SQL, verrous et mTLS réels, sur des appareils synthétiques. Le matériel, le média et le carrier restent à qualifier. La base principale du laptop conserve son schéma et son admission actuels.

De la fiche au combiné : la fiche d’un navigateur personnel actif et « Mes appareils » ouvrent ses paramètres avec une seule référence publique, jamais un secret. La sélection attend une nouvelle lecture personnelle. Un lien invalide ou un appareil absent donne une explication ; un autre titulaire doit utiliser sa propre session. Les homonymes restent distinguables par leur identité SIP. Une connexion active est conservée : préparer un autre appareil attend un arrêt explicite, sans connexion automatique. La recette finale passe 76 scénarios sans retry, dont 18 parcours appareil avec les vraies lectures applicatives sur une base synthétique. Les transports SIP et médias des autres scénarios restent simulés.

Connexion SIP du navigateur : dans les paramètres, la personne choisit son appareil et vérifie sa capacité avant de saisir le mot de passe SIP. Un appareil indisponible reste identifiable, sans champ secret. Le serveur revérifie la session, l'attribution, la génération et le runtime avant la connexion, puis pendant son maintien. Un mode V2 explicite ajoute les appels internes aux appareils dont les preuves sont complètes, y compris pendant une migration progressive. Les anciennes connexions gardent leur version et leurs capacités. Le client distingue transport ouvert et inscription confirmée ; aucune connexion n'est automatique.

Admission interne serveur raccordée : un mode explicite contrôle la source et tous les appareils du destinataire avant de sonner un poste de la même organisation. Les appareils V1 et V2 peuvent partager un groupe si leurs preuves désignent le même serveur vérifié. L'exécution reste liée à ce démarrage ; une perte de connexion retire son autorité. Après redémarrage, les anciens appels sont clôturés dans le journal sans commander le nouveau serveur. Une recette relie maintenant les vrais services, les preuves privées, les connexions chiffrées locales et le journal sur une base jetable. Elle couvre le répondant unique, les accès invalides et la coupure réseau. Le central reste simulé ; aucun appel ou trajet audio réel n'est qualifié.

Combiné SIP partagé : la connexion choisie dans les paramètres reste disponible entre pages et langues. Un mode explicite ajoute les appels internes : le serveur vérifie la cible avant composition et le canal d'un appel entrant avant affichage, puis avant réponse. Le microphone attend une action de la personne ; une annulation libère les pistes, y compris tardives. Le relais JSON et SIP ne fonctionnent pas ensemble. Une fermeture locale ne révoque pas le mot de passe SIP permanent. Les tests utilisent des transports et médias simulés ; le réseau, le chiffrement et l'audio réels restent à qualifier.

Le secret nouvellement généré ne doit apparaître qu’une fois. Il ne doit entrer ni dans le stockage du navigateur, ni dans les journaux, exports ou adresses de page.

Corrigé : protéger les accès existants. L’ancienne voie de configuration refuse désormais les appareils passés au nouveau protocole, avant de modifier le serveur téléphonique. Elle ne bascule pas automatiquement vers une autre procédure. La lecture indique les actions refusées et les opérations encore en attente, sans autoriser leur relance.

Enregistré ne signifie pas entièrement terminé. Si la création ou le renouvellement a été confirmé en base mais que le nettoyage final échoue, le résultat conserve le mot de passe à afficher une seule fois et signale l’intervention nécessaire. Une révocation confirmée reste elle aussi enregistrée. Le nettoyage ne rejoue pas l’action et ne supprime pas l’accès pour ce seul incident. Si la réponse entière se perd, le nouveau suivi durable retrouve le résultat et l’appareil, sans récupérer le mot de passe. Un renouvellement reste une décision explicite, après clôture de la demande.

Ces protections sont testées avec des pannes simulées, sans téléphone réel. Une liste de sessions illisible reste « non vérifiée ». La vue personnelle affiche le registre sans sonder Asterisk. Le centre administrateur intègre l’observation ponctuelle sur demande et l’historique des changements de configuration. L’historique des connexions et la recette de bout en bout restent à construire.

Relire les changements de configuration : « Voir l’historique » rassemble les 50 reçus les plus récents des parcours V1 et V2, y compris avant une migration. Création, renouvellement et révocation restent datés, avec leur génération et le résultat connu à ce moment. Une application V2 engagée mais non finalisée garde cette réserve ; une révocation non confirmée puis récupérée conserve les deux résultats. Un historique indisponible ne devient jamais une liste vide. La lecture reste privée, sans secret, sans sonde téléphonique et sans migration. Ces reçus ne prouvent ni la connexion actuelle ni le fonctionnement des appels.

Matrice d’accès conservée : les API téléphoniques autorisent les rôles owner, admin et operator, alors que les pages d’administration sont réservées à owner et admin. Les liens du catalogue suivent cette même distinction.

La fiche de préparation ne déduit aucun serveur, port, proxy, confiance TLS ou identifiant SIP matériel à partir de l’adresse du dashboard. Les capacités déclarées ne sont pas une configuration active. Les appareils révoqués, les opérations en cours et les lectures périmées empêchent les étapes de connexion. Le secret est effacé à la fermeture, à la perte de focus ou au masquage de l’onglet ; une réponse tardive ne le restaure pas après un retour.

La chaîne est dashboard → transport mTLS → service V2 durable → terminal HTTPS. Next reçoit les projections administratives et l'accès HTTPS lors de sa création ; il ne rend ni ne restitue le fichier de configuration ou son secret SIP. La remise au terminal utilise une lecture exacte du coffre, sans consommer la révélation administrateur ni créer une nouvelle version SIP.

Chaque inscription lie organisation, appareil, titulaire, poste, opération, génération, destination, cellule, profil et politique, avec le modèle, le firmware, la révision matérielle, la MAC et le compte. Le contexte privé lie également le démarrage et l'autorité runtime. Une rotation, une révocation, un propriétaire ou poste incohérent, un profil retiré ou un démarrage remplacé bloque l'ancienne inscription. Le contrôle est répété après la lecture du coffre.

La file d'exécution V2 reste protégée jusqu'à la fin ou à la fermeture bornée de la réponse HTTPS. Une inscription active bloque une seconde inscription du même appareil, compte et génération ; expiration ou nouvelle génération permettent un remplacement. La révocation reste possible après retrait du profil. Les gardes SQL imposent identités immuables, audit, version attendue et quota de 64 livraisons. Les reçus ne conservent ni fichier ni secret ; une admission sans fin confirmée reste inconnue.

Le seul profil navy-synthetic-lab-v1 produit un JSON synthétique. Il exige simultanément TELEPHONY_ENVIRONMENT=lab, LOCAL_ONLY=1 et un listener loopback. Aucun profil n'est activé par défaut et aucun adaptateur Yealink ou Snom n'est validé. Le suffixe .cfg de l'URL ne constitue pas une compatibilité constructeur.

La preuve de SIP Digest SHA-256 sur un firmware exact reste insuffisante pour les T31G, T54W et D385. L'authentification HTTPS, la confiance TLS initiale et les paramètres réellement appliqués doivent aussi être établis sur le matériel retenu. Ce manque reste un travail de qualification, sans réduction implicite des exigences SIP.

Validation du lot : 401 tests ciblés dans treize fichiers et six scénarios navigateur réussis. Les parcours couvrent le français, le néerlandais et l'anglais, à 390 et 1440 pixels. La recette conserve 18 captures ; douze contrôles Axe ne détectent aucune violation et aucun débordement horizontal n'est constaté. Ce compte reste propre au lot, sans cumul des campagnes historiques.

Les essais composent SQL, mTLS et HTTPS locaux avec coffre et téléphonie synthétiques. Un téléchargement HTTPS réel avec vérification de la CA retourne 200 et 465 octets synthétiques, puis un reçu sent. Après révocation, la même demande reçoit 503 sans corps. Cela confirme le contrôle de remise ; le fichier reste un JSON de laboratoire, sans preuve d'application sur téléphone, d'inscription SIP ou d'audio. Les quatre processus de la recette sont arrêtés et leurs groupes ne contiennent plus de processus.

La migration additive 0083_device_provisioning.sql concerne uniquement les bases neuves de recette ; aucune base conservée n'est migrée. Le lancement normal du laptop n'ouvre aucun listener de provisioning, aucun PBX et aucun appel externe. Les tests logiciels ne valent ni qualification matérielle, ni autorisation de pilote ou de mise en service.

Si la préparation HTTPS d'un appareil reçoit un refus de session ou de droits, le centre retire les fiches, les commandes et les secrets déjà affichés sur les autres appareils. Une création qui répond ensuite ne réaffiche pas son mot de passe. Une indisponibilité temporaire du service reste locale à la fiche concernée et permet une relecture.

Validation du 12 octobre : 200 tests ciblés et huit scénarios navigateur réussis. Six scénarios reproduisent le défaut sur la version précédente. Les contrôles couvrent les refus en lecture et en création, les réponses tardives et la reprise après une panne temporaire, avec deux fiches ouvertes en FR/NL/EN sur mobile et ordinateur. Les API d'appareils sont simulées ; aucun secret réel, service de configuration, PBX ou appel externe n'est exercé. Cette correction ne qualifie ni un téléphone physique ni la production.

Le transfert se prépare pendant un appel interne, puis se confirme volontairement vers un poste autorisé. Le serveur vérifie les participants actuels, leur appareil et le destinataire. Une réponse réseau perdue provoque une vérification de la même demande, sans envoyer un second transfert. La confirmation du transfert ne signifie pas que le destinataire a répondu.

Correspondant actualisé : la personne restée en ligne voit le nom et le poste confirmés par le serveur, y compris après un autre transfert. Le combiné distingue une conversation établie, une mise en relation, la messagerie et une identité momentanément indisponible. Il retire une ancienne identité lorsque sa vérification expire ; une réponse tardive ne peut pas l’afficher sur un nouvel appel. Le micro et l’attente conservent leur état. Un autre transfert exige un correspondant actuel confirmé.

La destination de messagerie ne signifie pas qu’un message a été enregistré. Une lecture indisponible ne signifie pas que l’appel est terminé. La vérification de l’identité ne commande aucun média et ne remplace pas les essais audio, téléphones et opérateur.

Lot précédent du correspondant courant, 23 septembre : 1 673 tests ciblés et 106 parcours navigateur réussis, sans relance. Les essais couvrent les trois langues, le mobile et l’ordinateur, ainsi que les réponses tardives et les changements de droits. La revue d’accessibilité et la vérification visuelle passent.

Le lot de transfert du 22 septembre a réussi 1 657 tests ciblés et 98 scénarios navigateur, avec parcours en français, néerlandais et anglais. Ces contrôles utilisent des bases temporaires et une téléphonie simulée. Ils ne prouvent pas l’audio, la compatibilité d’un téléphone physique ou un appel opérateur.

Ajout du 23 septembre : après une non-réponse, le correspondant resté en ligne peut laisser un message au nouveau destinataire. Le premier appel conserve son historique. Le message n’est pas accessible au participant qui a quitté l’appel du seul fait de sa participation, ni au nouveau titulaire d’un poste réattribué ; les droits d’administration restent distincts. La reprise vérifie le message déjà capturé sans rejouer l’annonce ou l’enregistrement, et termine le nettoyage des ressources même après un arrêt brutal. Ces preuves restent logicielles ; le redémarrage complet du matériel et le son réel ne sont pas qualifiés. La base principale du laptop reste sans ces nouvelles migrations ; le moteur d’appels et les appels externes restent désactivés.

La réunion explicite et la liste des participants sont raccordées au combiné sous activation dédiée, en FR/NL/EN. Pendant une consultation établie, la personne qui l’a lancée peut choisir de réunir les trois personnes. Le serveur conserve cette demande et chaque opération, puis vérifie les participants avant de confirmer le groupe. Une réponse perdue provoque la lecture du même résultat, sans répéter la réunion.

Une liste actuelle, distincte du reçu de création : chaque participant voit sa propre vue de la conversation, après vérification de ses droits et d’observations fraîches du serveur. Si cette preuve expire, les noms sont retirés et l’interface indique que les participants ne sont plus confirmés. Le micro et le bouton de sortie concernent uniquement sa propre participation. Le créateur ne dispose pas de commandes pour couper les autres ; la mise en attente du groupe n’est pas proposée.

Après le départ de l’un des trois membres, les deux survivants peuvent poursuivre la conversation. Le début et la durée maximale de l’appel sont conservés. Un nouveau transfert ou une nouvelle consultation attend une conversation à deux confirmée. Pendant la réunion, les anciennes commandes de retour et de transfert de la consultation sont retirées.

Destinataire visible après un transfert : la sonnerie et le passage à la messagerie conservent le nom et le poste vérifiés, même lorsque la conférence est activée. Le combiné exige deux lectures fraîches concordantes du même appel. Une divergence ou une preuve expirée retire cette identité. Le destinataire n’est pas présenté comme connecté et les actions de transfert, de consultation et de mise en attente attendent toujours une conversation à deux confirmée.

La reprise après interruption ferme le propriétaire courant et récupère ses ressources après vérification. Elle ne promet pas de rétablir le son après un redémarrage. Les recettes utilisent un journal réel sur des bases temporaires, une téléphonie simulée et un navigateur avec transport intercepté. Elles ne qualifient pas le son, les téléphones physiques ni l’opérateur.

Le parcours répond au besoin d’appel à trois décrit par Telavox, sans démontrer une parité avec leur suite. Aucun PBX réel, appel externe, changement de la base conservée ou déploiement de l’application n’est effectué par ce lot.

Une clôture vérifiée : le centre /admin/call-incidents distingue une demande enregistrée, une vérification en cours, un blocage expliqué et une clôture confirmée. Le parcours existe en français, néerlandais et anglais. Une réponse perdue conduit à relire la même demande ; elle ne déclenche pas une seconde opération.

Le service de reprise peut fonctionner lorsque le moteur d’appels refuse de démarrer. Il vérifie l’appel courant et toutes les ressources couvertes avant de conserver son reçu et de terminer l’historique dans une même transaction. L’incertitude des anciennes commandes reste conservée. Une admission fermée ne donne aucun droit de couper un appel vivant.

Sur le même processus téléphonique, aucune mutation antérieure ne doit encore pouvoir créer ou déplacer une ressource. Une suppression déjà tentée n’est pas répétée. Après remplacement prouvé du processus, les anciens canaux ne sont ni interrogés ni commandés. Le traitement reste possible sans nouvel appareil de connexion utilisable et n’ouvre jamais les appels.

Un relais déjà admis vers la messagerie native conserve son propre traitement de reprise et reste explicitement indisponible dans ce centre. Une ancienne base affiche également cette limite, sans migration automatique. Les essais utilisent des bases jetables, des connexions chiffrées locales et une téléphonie simulée. La recette matérielle, audio, réseau et opérateur reste à réaliser.

Quand une nouvelle connexion prend la place de l’ancienne auprès du serveur téléphonique, l’ancien client ferme sa connexion et refuse les commandes suivantes dès notification. Une commande déjà envoyée conserve un résultat incertain. Les événements arrivés trop tard ne doivent ni publier un message ni relancer un enregistrement. Si la perte intervient pendant le démarrage, une lecture retardée ne peut plus annoncer le moteur prêt.

La reprise de messagerie partage ce contrôle. Après un remplacement du moteur ou une coupure de sa connexion, une réponse tardive ne peut plus déclencher un arrêt ou une suppression d’enregistrement. La capture reste en attente de reprise, sans publication de message.

La recette a aussi corrigé le démarrage du mode historique sur le schéma actuel : il exige une base conforme et la preuve qu’aucune ressource de transfert ne lui appartient. Une ligne incohérente reste bloquante. Les essais utilisent des connexions locales et des bases jetables ; aucun PBX réel n’est lancé et la base conservée du laptop n’est pas migrée.

Cette réaction à une notification reste distincte du nouveau profil propriétaire optionnel décrit ci-dessous. L’authentification de l’entrée opérateur demeure nécessaire avant le dépôt dans une boîte partagée. Le matériel, l’audio et l’opérateur restent à qualifier.

Un profil optionnel confie le contrôle téléphonique au broker de cellule. Le moteur et le journal des appels restent centraux. Le broker réserve durablement une seule session, vérifie la politique réellement chargée et le démarrage du serveur, puis porte ensemble les événements, les commandes et les lectures de messagerie. Un fichier de configuration rendu ne suffit pas à autoriser ce contrôle.

Une connexion perdue bloque un nouveau propriétaire sur le même démarrage, même après un redémarrage du broker. Un arrêt volontaire du client ne prouve pas que toutes les opérations sont terminées. Les commandes incertaines ne sont pas répétées et une ancienne session ne peut plus relire le réseau. Le remplacement exige une nouvelle preuve physique ; les incertitudes précédentes restent dans l’historique.

Les essais utilisent de vrais journaux SQL temporaires et des connexions chiffrées locales, avec un serveur téléphonique, des contrôles de politique et des médias simulés. Les files et journaux sont bornés ; leur authentification ne protège pas contre la restauration d’une ancienne copie complète. Ce profil reste désactivé sur le laptop, sans migration de sa base conservée. La qualification d’Asterisk réel, de son réseau, du matériel et de l’audio reste à faire ; la préparation de l’entrée opérateur est raccordée en simulation, avec un dépôt et un lecteur partagés raccordés sous activation distincte en simulation.

Le serveur vérifie maintenant l’appel entrant, sa route et la boîte partagée dans un même parcours privé. Le profil lie chaque numéro au déploiement nommé dans la configuration centrale et aux routes réellement chargées dans la passerelle. Le contrôle utilise la session sécurisée qui possède déjà le moteur d’appels ; il ne crée aucun téléphone de substitution.

Deux lectures du canal entourent la vérification locale. Un canal disparu, remplacé ou incohérent est refusé. La préparation relit ensemble l’attribution du numéro, la qualification opérateur, les horaires, la boîte active et ses lecteurs explicites. Une révocation produit un nouvel instantané de droits. La qualification et les horaires sont revérifiés après le dernier contrôle du propriétaire.

Préparer la destination ne déclenche pas d’enregistrement. Sans activation complète du service partagé, le moteur refuse toujours ce parcours média. Le profil optionnel vérifie l’annonce montée avec le propriétaire actuel ; le service raccordé peut ensuite admettre atomiquement l’appel et le dépôt, attendre l’annonce complète, capturer puis publier le message chiffré. Une réponse tardive ne rétablit pas une session perdue.

Les essais utilisent des bases temporaires, de vraies connexions locales sécurisées et des composants téléphoniques simulés. Le profil reste désactivé sur le laptop, sans migration de la base conservée. Les téléphones physiques, le son et l’opérateur restent à qualifier.

Un appel dirigé vers une file fermée peut désormais alimenter sa boîte partagée. Sous activation dédiée, le service réserve ensemble l’appel, sa branche et le dépôt. Il vérifie la destination, les lecteurs et l’annonce du propriétaire courant, puis attend la fin de cette annonce avant d’enregistrer. La réponse technique nécessaire à l’annonce ne compte jamais comme une réponse humaine.

Le WAV est vérifié après la fin d’écriture, conservé sous forme chiffrée et publié avec son enregistrement et son audit dans une même transaction. Les raccrochages et nettoyages ont un reçu durable : une réponse perdue ne permet pas de répéter la commande. Une reprise peut terminer une publication déjà capturée sans rejouer l’annonce ou l’enregistrement. Une création d’enregistrement non confirmée reste explicitement incertaine.

La boîte de réception partagée est accessible depuis les messages personnels, en FR/NL/EN. Le chargement audio exige un clic ; le marquage comme lu reste distinct. Liste et écoute exigent l’attribution historique encore active, y compris pour un administrateur. Les droits sont revérifiés après déchiffrement : une révocation concurrente refuse les octets. Réajouter une personne ne lui rend pas ses anciens messages.

La campagne du raccord complet valide 505 tests ciblés dans 24 fichiers, puis neuf parcours navigateur avec les vraies API sur une instance jetable. Elle couvre FR/NL/EN à 390 et 1440 pixels, les droits, une réponse perdue après marquage et les états d’indisponibilité. Les octets audio synthétiques sont vérifiés ; la lecture native du navigateur est simulée. TypeScript, ESLint et l’audit i18n passent.

Les essais composent des bases jetables, des fichiers chiffrés et de vraies connexions locales sécurisées, avec une téléphonie simulée. Le profil reste désactivé sur le laptop et sa base conservée n’est pas migrée. La qualification d’Asterisk, des téléphones, du son et de l’opérateur reste nécessaire. Le coffre distant reste absent de ce profil. L’effacement gouverné des messages publiés et clos dispose maintenant d’un parcours distinct, décrit ci-dessous.

L’administration des données peut effacer un message partagé publié dont l’appel est clos. Le demandeur et l’approbateur doivent être distincts. Le serveur revérifie les droits actuels, l’absence de conservation légale et le contenu exact du périmètre approuvé. Un nouveau marqueur de lecture ou un fichier remplacé bloque une ancienne approbation, même si le nombre d’objets reste identique.

L’accès est retiré avant toute modification du fichier. L’effacement traite ensuite le fichier chiffré local et les lignes métier couvertes ; il conserve les audits et une preuve minimale sans contenu audio. La fin n’est confirmée qu’après disparition du fichier original et du fichier de préparation. Une interruption avant la suppression en base peut restaurer les octets exacts, sans rendre l’accès au message. Après la suppression en base, la reprise termine uniquement l’effacement physique.

Une réponse perdue ne provoque aucun second envoi automatique. Le dashboard demande une relecture et bloque les actions sur une lecture non confirmée. Une exécution encore active reste exclusive. Après un arrêt brutal, la reprise exige une preuve du système local que le processus précédent a disparu, jamais un simple délai. Les tests couvrent de vrais arrêts de processus avant et après l’écriture en base, sur des données synthétiques.

La campagne confirme 305 tests ciblés dans 23 fichiers et neuf parcours navigateur sur une instance jetable. Les écrans sont vérifiés en français, néerlandais et anglais, sur mobile et ordinateur. Les parcours utilisent les vraies API : approbation par un autre compte, suppression des fichiers et lignes, réponse perdue après effacement, modification du périmètre et session révoquée. TypeScript, ESLint, audit i18n et contrôles d’accessibilité passent.

Le parcours exige un nettoyage téléphonique déjà confirmé et une publication terminée avec preuve durable. Les anciennes publications sans cette preuve restent inéligibles. La migration additive porte le code à 83 migrations ; les bases conservées ne sont pas migrées. L’export partagé, la purge automatique, le coffre distant et l’effacement du registre des boîtes restent hors périmètre. Les essais logiciels ne qualifient ni Asterisk déployé, ni les téléphones, ni le son, ni l’opérateur.

La boîte et sa révision désignent une annonce précise, configurée des deux côtés. Le profil optionnel prépare uniquement les sons approuvés dans le répertoire protégé du serveur. Le contrôle vérifie les réglages réellement chargés, le montage en lecture seule, le processus et les octets du WAV. Une variante de format, de langue ou de nom qui pourrait remplacer ce son est refusée.

La réponse passe par la connexion sécurisée du propriétaire actuel du moteur. Elle reste liée à cette connexion et expire rapidement. Une réponse tardive, un fichier remplacé ou une perte de contrôle ne rendent pas une ancienne preuve utilisable. La configuration actuelle de la boîte et l’autorisation d’enregistrement sont aussi relues avant cette préparation.

Vérifier l’annonce ne déclenche pas de capture. Les essais utilisent des fichiers réels, des bases temporaires et des connexions locales sécurisées, avec les processus et réponses téléphoniques simulés. Le profil reste désactivé sur le laptop. L’écoute réelle de l’annonce, les téléphones et l’opérateur restent à qualifier.

La lecture et l’export d’un enregistrement vérifient de nouveau la session, les droits et l’identité du fichier après son chargement. Une révocation de session ou un changement de poste ou de rôle qui retire l’autorisation empêche la restitution. Un refus ne crée pas d’audit de lecture réussie.

Les tests emploient de vrais fichiers et une base temporaire, avec une lecture volontairement suspendue pour provoquer ces changements. Ce correctif protège les lecteurs existants ; il n’ouvre pas l’écoute des nouveaux dépôts partagés.

Demander l’arrêt et terminer les opérations sont deux étapes distinctes. Le service ferme ses nouvelles admissions et ses tâches périodiques dès l’arrêt demandé. Les écritures, publications de messages et nettoyages déjà engagés restent suivis, même lorsque leur délai d’attente est dépassé. Le verrou local du processus est conservé jusqu’à la fin de ce travail et de ses compensations.

Un résultat de démarrage qui arrive après l’arrêt est fermé avant de pouvoir être utilisé. Une ancienne instance de messagerie ne peut pas être réouverte ; la reprise construit une nouvelle instance. Les essais couvrent des commits SQL retardés, des fichiers audio temporaires et des opérations téléphoniques simulées qui ignorent l’annulation.

Ce suivi ne prouve pas, à lui seul, que toutes les ressources téléphoniques ont disparu ni que chaque résultat durable est réconcilié. La perte du contrôle continue donc de bloquer un nouveau propriétaire sur le même démarrage. La libération contrôlée de la cellule et sa qualification sur Asterisk réel restent à réaliser. Aucun moteur d’appels ni migration de la base conservée n’est lancé sur le laptop pour ce lot.

La campagne initiale de ce suivi validait 1 131 tests dans 52 fichiers complets, dont les 17 contrôles ciblés de démarrage et d’arrêt. Les six cas du dashboard de conférence alors ouverts passent désormais dans la recette du 6 octobre décrite ci-dessous, avec les mêmes délais de sécurité. La qualification sur téléphonie réelle et sous charge contrôlée reste à réaliser.

Les vérifications communes d’un journal de consultation sont regroupées dans une même lecture fraîche. Sur une base identique et avec le même résultat, le nombre de requêtes passe de 14 à 10. Les données et les autorisations restent relues ; aucun résultat d’autorité n’est conservé pour une demande suivante.

Pendant un transfert direct, le dashboard évite aussi de relire une publication qui ne peut pas encore exister. Il conserve la distinction entre une transition et une paire réellement connectée, le contrôle des participants et la limite de fraîcheur de 2,5 secondes.

Ces réductions de travail ne constituent pas une qualification sous charge contrôlée. Les téléphones, l’audio et l’opérateur restent à tester sur les équipements réels.

Deux demandes concurrentes ne peuvent plus remplacer successivement le mot de passe depuis le même état ancien. Le serveur relit la session et la version du compte avant l’écriture. Le nouveau mot de passe, la révocation des autres connexions et l’audit sont enregistrés ensemble. La session initiatrice reçoit uniquement la version qu’elle a réellement confirmée.

Le formulaire distingue un mot de passe actuel incorrect, une session refusée et une modification concurrente, en français, néerlandais et anglais. L’attente est bornée. Si la réponse se perd, il indique que le résultat reste inconnu, bloque un nouvel envoi et propose de se reconnecter avec le nouveau mot de passe. Aucune requête de modification n’est répétée automatiquement.

Les 218 tests ciblés et les neuf scénarios navigateur passent. Les essais utilisent des comptes synthétiques et des bases jetables, dans les trois langues, sur mobile et ordinateur. Ils couvrent la concurrence réelle entre deux connexions SQL, la révocation pendant le calcul, le rollback de l’audit et une réponse perdue après enregistrement. Aucun mot de passe des instances conservées n’est modifié.

Le premier démarrage est réservé à des données neuves. Il refuse une base, des accès ou des fichiers déjà présents et indique la reprise explicite à utiliser. Une nouvelle vérification empêche aussi d'adopter des données apparues pendant la préparation. La reprise conserve la base et les accès, sans migration ni provisionnement.

Le diagnostic affiche séparément la réponse de l’application, les dépendances et l’alignement du journal de migrations. Il vérifie toutes les dates et empreintes du journal. Le lancement d’une nouvelle instance applique désormais 86 migrations sur une base neuve. Les bases historiques laptop-dev.kQEEYo, laptop-dev.current82, laptop-dev.current83, laptop-dev.current84 et laptop-dev.current85 restent conservées à 41, 82, 83, 84 et 85 migrations. Le suivi durable des demandes d’appareils ajoute sa migration uniquement aux nouvelles bases ; il ne migre aucune de ces bases conservées.

Pour ce contrôle, SQLite lit une copie temporaire privée avec son journal de transactions ; la base conservée est seulement lue comme un fichier. Les empreintes sont revérifiées, les lectures trop longues sont interrompues et la copie est nettoyée. Un changement en cours, une divergence ou une lecture impossible reste signalé, sans réparation automatique. Un journal aligné ne prouve pas l'intégrité complète du schéma.

Les nouvelles instances locales gardent des connexions indépendantes. Chaque instance neuve conserve son propre cookie de session. La connexion ou la déconnexion sur un autre port ne remplace plus celle de la première instance. Une reprise conserve les sessions encore valides. Les anciennes configurations gardent leur cookie historique et ne sont pas réécrites ; la préférence de langue reste commune au même hôte.

Le lot des sessions indépendantes a été vérifié par 171 tests ciblés et un scénario navigateur avec deux instances réellement démarrées, leurs bases neuves alors alignées sur 82 migrations et un seul navigateur. La recette contrôlait arrêt et reprise sans réensemencement, vrais formulaires, quatre API de lecture sur chaque instance et écrans appareils, messageries et supervision. Une session déconnectée restait refusée lors d'un rejeu. Ces lectures ne prouvent ni présence matérielle ni téléphonie opérationnelle.

Les parcours de test utilisent les accès générés dans leur propre instance neuve. Une réponse HTTP réussie ne suffit pas à qualifier les fonctions téléphoniques. Le lancement normal du laptop n'ouvre aucun listener de provisioning, aucun PBX et aucun appel externe ; le matériel, l'audio et l'opérateur restent à qualifier.

Le centre administrateur conserve les vingt demandes personnelles les plus récentes. Une recherche par référence et un lien durable permettent désormais de rouvrir une demande plus ancienne, dans une zone distincte de cette liste. Le résultat reste lié à l’administrateur qui l’a créée et à son organisation ; un lien ne donne aucun droit supplémentaire.

Ouvrir le lien, chercher ou actualiser ne crée aucune demande et ne révèle aucun accès. Une remise de secret exige toujours une action explicite et les vérifications actuelles de l’appareil. Pendant une actualisation, le résultat précédent est signalé comme ancien, les actions sont bloquées et le focus clavier reste stable. Replier une demande efface son secret, même si une lecture est encore en cours.

Les 307 tests ciblés et les 13 scénarios navigateur du lot passent. La recette couvre FR, NL et EN, le mobile et l’ordinateur, une demande sortie des vingt plus récentes, le rechargement de son lien et la séparation des utilisateurs et organisations. Les essais utilisent une base isolée, le vrai service administratif et un coffre ainsi qu’un serveur téléphonique simulés. Les téléphones physiques, le son et l’opérateur restent à qualifier. La base conservée du laptop reste à 41 migrations, sans lancement de PBX ni appel externe.

Le pilote local réutilise désormais les connexions des transactions terminées lorsque leur remise en état est confirmée. Les opérations conservent leurs données isolées et leurs contrôles de préparation. La recette vérifie aussi la compatibilité d’une base chiffrée. Un résultat tardif d’une ancienne connexion ne peut pas rouvrir un client fermé.

Le test de 100 transactions successives obtient un nombre stable de connexions, sans nettoyage mémoire forcé. Des ressources restent présentes après la fermeture logique : cette mesure ne promet ni une libération instantanée complète ni une capacité générale sous charge.

Recette logicielle du 6 octobre : 1 529 tests validés dans 72 fichiers complets. Les six scénarios du dashboard de conférence passent, notamment les vues personnelles des participants, les sessions révoquées, les réponses perdues et le retour à deux interlocuteurs. Les tests utilisent une vraie base temporaire et un moteur téléphonique simulé ; les délais de sécurité restent inchangés.

Chaque fichier a été exécuté dans un processus séparé, avec une limite mémoire. La campagne commune interrompue à cette limite est exclue du compte. Ces preuves ne remplacent pas les essais de longue durée, les téléphones, l’audio ou l’opérateur réel.

Le moteur privé fait sonner le destinataire et lui présente la personne qui souhaite le consulter. Après sa réponse, leur conversation reste isolée du correspondant initial. Les deux participants peuvent lancer une consultation, y compris après un transfert direct. Pendant la consultation privée, aucun pont ne doit mélanger les trois personnes. Une réunion exige une demande de conférence distincte.

Retour et transfert confirmés : une annulation ou une non-réponse rétablit la conversation initiale puis publie son nouvel état. Une confirmation transmet l'appel au destinataire déjà en ligne, sans le rappeler. Le correspondant courant suit le résultat vérifié ; les réponses anciennes ne rétablissent pas une ancienne identité. Les droits et les appareils sont revérifiés avant la publication. La messagerie configurée reste intacte et ne s'exécute pas pendant la consultation.

Reprise vérifiée : le nettoyage contrôle les identités avant les effets et confirme leur absence. Les essais composent consultation, transfert direct et reprise du service. Un processus remplacé ne donne aucun droit sur les anciens identifiants réutilisés. Retirer l'activation n'abandonne pas les ressources déjà enregistrées par ce nouveau parcours. Une preuve manquante laisse la reprise bloquée.

Commandes du combiné raccordées : consulter, revenir au correspondant et confirmer le transfert sont disponibles sous activation dédiée, en FR/NL/EN. Une réponse perdue déclenche la lecture de la même demande, sans la renvoyer. L'interface retire les actions lorsque leur état n'est plus vérifiable. Les parcours navigateur couvrent retour, confirmation et réponses perdues à 320 et 1440 pixels, avec contrôles d'accessibilité.

Commandes expirées : une demande de retour ou de confirmation expirée avant son exécution possède désormais une reprise contrôlée : le serveur vérifie l'absence d'effet et l'état actuel de la consultation. Une nouvelle action exige un nouveau clic. Si le destinataire est parti ou que la sonnerie est terminée, le serveur prépare le retour vers le correspondant ; il ne répète pas un transfert expiré. L'interface distingue cette preuve d'une réponse simplement perdue.

Poursuite avec le collègue : lorsque le correspondant initial raccroche pendant la conversation privée, les deux personnes encore en ligne conservent leur connexion, sans nouvel appel. Le serveur vérifie leur présence et le départ du correspondant avant de publier la poursuite. Une commande déjà en cours d'exécution ou un effet incertain empêche cette décision. L'ancien pont vide est nettoyé séparément, sans couper la conversation si ce nettoyage échoue. Le combiné explique le changement en FR/NL/EN et attend la confirmation du nouveau correspondant avant de permettre un autre transfert.

Un nettoyage incomplet peut encore bloquer le redémarrage du moteur d’appels. Le centre d’administration permet désormais de demander une résolution ciblée à un service distinct, avec preuve de clôture. Une commande historiquement incertaine peut concerner un appel déjà terminé : son état reste conservé et le nouveau reçu décrit séparément la clôture opérationnelle. La recette complète des enchaînements sur le matériel réel reste à réaliser. Les essais utilisent le vrai journal SQL sur des bases neuves jetables et une téléphonie simulée. Les nouvelles migrations ne sont pas appliquées à la base principale du laptop. Aucune qualification audio, téléphone physique ou opérateur n'est déduite de ce lot.

La recette réunit maintenant le démarrage du nouveau service, la remise en place vérifiée des appareils et la reprise d’une conversation transférée, y compris après un second transfert. Si le processus téléphonique est remplacé, ses anciens identifiants ne permettent jamais de toucher une autre conversation sur le nouveau processus.

Un message déjà publié est conservé, sans doublon. Un enregistrement dont la publication n’était pas confirmée reste signalé comme incertain. Sur le même processus, le nettoyage vérifie les participants et constate leur disparition avant de conserver son reçu. Une reprise ne répète pas les commandes déjà accomplies.

Un historique important d’appels et de messages clos ne bloque plus ce travail. Une opération de démarrage annulée ne peut pas modifier le journal plus tard ; une transaction interrompue annule aussi son audit. Ces contrôles utilisent les vrais journaux et reprises de configuration, avec une observation du processus et des médias simulés.

La migration additive 0070 ajoute la preuve de nettoyage. Les 71 migrations sont vérifiées uniquement sur des bases neuves jetables ; la base principale reste à 41. Les essais sur un vrai Asterisk, le réseau audio, les téléphones SIP/DECT et l’opérateur restent à réaliser. La campagne de reprise valide 774 contrôles logiciels ciblés dans 37 fichiers. Les chiffres du lot précédent restent séparés.

Raccordement développé et testé, pas encore activé dans l'application. Le nouveau chemin conserve l'audio et le travail à effectuer ensemble. « Accepté » ne signifie pas « traitement terminé ». Si le résumé échoue, la reprise réutilise la transcription déjà validée ; un ancien traitement qui répond trop tard ne peut plus remplacer le résultat courant.

Les fichiers audio sont vérifiés avant traitement, y compris lorsqu'ils sont chiffrés. Une panne de reconnaissance vocale ou de résumé est signalée comme une panne. Si aucun modèle n'est configuré, les deux premières phrases sont proposées comme un extrait, pas comme un résumé produit par l'IA. Une notification dont l'envoi reste incertain n'est pas renvoyée automatiquement.

Demander l'arrêt ne suffit pas : la copie de transcription reste protégée jusqu'à la fin réelle du processus. Ensuite, un nettoyage incomplet reste signalé dans le résultat de la tentative et peut être repris pour les copies explicitement libérées. Les copies actives, anciennes ou ambiguës sont conservées ; leur âge ne suffit jamais à autoriser leur suppression.

Une requête de transcription qui tarde à se fermer arrête les nouvelles prises de ce passage du service. Cela ne prouve pas l'arrêt du calcul chez le fournisseur. Le contrôle de ces alertes après redémarrage reste à construire.

Un arrêt brutal peut encore laisser une copie privée ou bloquer son nettoyage. La récupération complète reste à qualifier avant activation. Un envoi cloud déjà parti peut aussi créer une version supplémentaire, même si sa réponse arrive trop tard pour modifier le résultat.

Si l'envoi est refusé parce que son autorisation a expiré ou que le fichier serveur est endommagé, le navigateur garde sa copie. Cela ne contourne pas l'autorisation : la procédure de récupération et de rétention reste à construire. Le traitement des enregistrements et l'envoi des notifications sont deux services séparés, à démarrer explicitement.

La base du laptop n'a pas été migrée ; aucun modèle ni service cloud lancé. Les tests utilisent des données et fournisseurs simulés. Le nettoyage après arrêt brutal et la reprise en conditions réelles restent à qualifier. Ce lot ne prouve ni la qualité de la voix ni un gain de latence en appel.

Testé avec des destinataires simulés, désactivé par défaut. Le nouveau service prépare une notification pour un seul destinataire. Il revérifie les droits et la destination avant l'envoi. Un email invite à consulter Navy Phone ; il ne contient ni audio, ni transcription, ni résumé.

« Accepté par le fournisseur » signifie qu'un accusé de réception a été conservé, pas que la personne a reçu ou lu le message. Si l'envoi n'a pas pu commencer, il est signalé comme non envoyé. Si la réponse se perd après le départ de la requête, le résultat reste inconnu : aucun renvoi automatique. Une confirmation tardive peut préciser le résultat.

Une limite temporaire d'envoi conserve la notification en attente. Le mode « local uniquement » interdit tout départ. Les adresses réseau privées, les redirections et les destinations non autorisées sont refusées dans ce nouveau chemin.

Le service avance par lots de vingt intentions au plus et s'arrête sur un résultat incertain. Sa reprise de parcours ne prouve pas que toute la file est traitée. Le fournisseur email existant, Resend, reste soumis à une validation séparée de souveraineté et à une activation explicite. Aucun message réel envoyé ni base du laptop migrée pour ce lot.

Ajouter une transcription ne modifie plus la preuve audio initiale. Lors d'un nouvel envoi de la même capture, le serveur conserve sa date et sa preuve d'origine, revérifie l'audio et le journal d'audit, sans créer de nouveaux objets. Une panne du VoiceBot après scellement n'empêche plus cette vérification ; avant le premier scellement, elle reste bloquante.

Les emails de message vocal et d'appel manqué ne sélectionnent plus le propriétaire d'un poste dans une autre organisation. Le repli de messagerie vers les administrateurs de l'organisation reste en place. Un retour sans erreur ne prouve pas la livraison d'un email.

Les tests utilisent le vrai traitement métier sur une base temporaire, avec IA, stockage et notifications simulés. Ils refusent aussi les preuves, dates ou journaux altérés. Ce correctif ne réalise pas encore la reprise automatique d'un traitement interrompu. La vérification d'audit parcourt tout le journal ; son coût augmente avec l'historique et ce n'est pas un témoin externe immuable.

Le dashboard peut soumettre une création, un renouvellement ou une révocation au service privé V2. La demande reste visible après rechargement, même avant l’apparition de l’appareil dans le registre. Une destination autorisée est choisie à la création puis conservée. Le secret est remis une seule fois, sur action explicite, après validation de la configuration.

Les essais FR/NL/EN traversent les vraies routes de l’application, le transport mTLS, les journaux SQL et le worker, avec un coffre et des appareils simulés. Une panne conserve son état de vérification et ne provoque aucun nouvel envoi automatique. Ce parcours configure les navigateurs et les profils matériels explicitement proposés. Les modèles restent soumis au niveau de preuve du catalogue. La migration progressive dispose de son parcours logiciel vérifié séparément. Le carrier, le média, les téléphones réels et l’identité du vrai processus Asterisk restent à qualifier. Une configuration appliquée ne prouve ni un appareil connecté ni un appel réussi.

Le combiné distingue la mise en attente, la demande encore en cours et le micro coupé. Reprendre conserve le réglage du micro et ne lève pas une attente demandée par le correspondant. Les commandes restent attachées à l’appel courant ; une réponse tardive ne peut pas reprendre un ancien appel.

Les parcours existent en français, néerlandais et anglais. Les essais utilisent le moteur SIP installé avec une signalisation et des médias synthétiques. Le son, la musique d’attente et le comportement sur téléphones réels restent à qualifier.

Le combiné vérifie les appels sortants et entrants avec les preuves actuelles des appareils. Une offre entrante doit correspondre au bon appel dans le journal. Les refus sont expliqués en français, néerlandais et anglais, avant toute composition ou acquisition du microphone. Le renouvellement d'une connexion ne peut pas changer silencieusement ses capacités.

Le routage, la réponse du destinataire, le raccrochage et la messagerie native sont raccordés au serveur vérifié. Un redémarrage sépare les nouveaux appels des anciens journaux ; une capture incertaine reste identifiée comme telle. Les tests couvrent les groupes V1/V2 et V2/V2, les pertes d'autorité et les événements tardifs avec des appareils synthétiques. L'activation sur le laptop reste fermée. Asterisk réel, les téléphones, l'audio et l'opérateur restent à qualifier.

La preuve actuelle du cycle de vie est rejouée dans la VM x86_64. Le laboratoire antérieur en conteneur ARM64 vérifiait le transport HTTPS et mTLS, les inventaires signés, le refus d’un inventaire indisponible, les reprises et la conservation du journal. Un inventaire introuvable ne signifie plus « aucun appareil ». Les réponses Asterisk sont synthétiques.

La VM x86_64 vérifie les arrêts des dépendances, la reprise après crash, le refus d’un bundle corrompu, sa restauration exacte et la persistance après coupure. Le laboratoire ARM64 reste une preuve historique pour les sources précédentes ; il ne qualifie pas les nouveaux contrôles d’entrée. Les environnements jetables des essais terminés ont été nettoyés. Ces essais ne prouvent ni l’identité d’un vrai processus Asterisk, ni une inscription SIP, ni l’audio. Le parcours logiciel des appels V2 est désormais raccordé ; la qualification d’un vrai appel reste distincte. L’ancien rapport de laboratoire Asterisk du 1er septembre ne correspond plus aux sources et reste explicitement historique.

Le titulaire, le poste et la génération sont vérifiés avant et après la lecture de connexion. Une rotation terminée pendant la lecture retire l'ancien résultat. Chaque reçu montre son opération, sa génération et sa provenance ; une révocation vérifiée reste identifiée comme telle.

Si la fiche a changé ou si les preuves se contredisent, les diagnostics sont retirés et une actualisation est requise avant de préparer ou modifier l'appareil. Les lectures bloquées expirent. Le nouveau port de lecture V2 vérifie la cellule, le démarrage réel et l'admission via son broker. Une preuve ancienne sans cette liaison reste indisponible. Ces contrôles ne qualifient ni un appel ni un téléphone physique.

Avant de rouvrir une cellule, le serveur vérifie les preuves et l’inventaire des appareils. Une annulation, un délai dépassé ou la perte de son verrou exclusif empêchent maintenant une réponse tardive de rouvrir les accès.

La dernière écriture conserve le verrou jusqu’à la fin de sa transaction. Les essais utilisent une base jetable et un vrai verrou local, avec des lectures synthétiques. Ils ne qualifient pas une reprise Linux ou un téléphone réel. L’affectation durable des appareils aux cellules est désormais imposée avant la première commande. Les mutations V2 du centre administrateur sont désormais reliées au service privé et au journal durable.

Après un changement d’autorité, la reprise produit une nouvelle preuve signée et conserve le journal d’origine. Les confirmations perdues peuvent être reprises sans attribuer les anciens reçus à la nouvelle autorité. Les contrôles distinguent la reprise sur le même démarrage Asterisk et celle après un nouveau démarrage ; seule la preuve liée à l’autorité et au démarrage courants permet l’observation.

Les bases SQL, signatures et verrous locaux sont réels dans les essais ; l’application de la configuration et le runtime sont simulés. Le matériel, les appels et la reprise Linux restent à qualifier. Le rattachement immuable réserve chaque appareil à sa cellule avant la première commande. La réconciliation contrôle ensuite les seuls appareils de cette cellule. Les barrières de mutation restent globales ; la migration progressive V1 vers V2 exige maintenant une campagne privée et une preuve du système source. Le centre administrateur dispose maintenant de son parcours durable V2.

Une commande conserve maintenant une tentative distincte pour chaque autorité qui la reprend. Le reçu indique qui a réellement appliqué la configuration ; un ancien effet ne peut plus être présenté comme celui du nouveau service. Les effets et preuves précédents restent conservés.

Demander l’arrêt du coordinateur interdit les nouvelles écritures. Les écritures de coffre engagées et les confirmations en base gardent chacune le verrou jusqu’à leur fin réelle. Les lectures peuvent être annulées. Une version déjà envoyée est ensuite vérifiée par lecture exacte, sans nouvel envoi. Les essais utilisent des bases jetables, de vrais verrous locaux et des fournisseurs simulés. Le service d’administration V2 et son suivi dans le dashboard sont raccordés ; aucune base principale migrée ni téléphonie réelle activée.

La supervision utilise maintenant le broker de la cellule pour les navigateurs V2. Chaque source conserve sa couverture, sa date et son motif d’incertitude. Une panne ne transforme pas une absence de mesure en appareil hors ligne. Chercher un collègue et préparer son poste restent possibles ; appeler exige une connexion qui l’autorise.

Les lectures sont bornées et réparties entre les passages. La recette utilise SQL et mTLS réels avec un runtime synthétique. La réconciliation répartit les appareils selon leur affectation durable ; la bascule complète vers V2 et les barrières de mutation restent globales. Le matériel, le son, le carrier et la nouvelle qualification Linux restent à prouver.

La lecture V2 utilise un certificat réservé à une organisation et une cellule, sans droit de modification des appareils. Le broker relie l'effet appliqué au processus Asterisk et vérifie le credential installé. Le dashboard contrôle le registre avant et après cette lecture. Une absence complète peut être diagnostiquée, mais ne permet aucune connexion.

Le bouton d'observation reste utilisable sans configuration ARI V1 globale et indique sa provenance broker. L'inscription V2 reste séparée des appels. Les tests utilisent des bases jetables, des certificats temporaires et un runtime simulé. Le nouveau bundle attend encore sa recette Linux ; aucun PBX, téléphone ou opérateur réel n'est qualifié.

La supervision indique les appareils observés, ceux en ligne et ceux présentant une activité. Elle conserve les indications positives d’une observation partielle et distingue un appareil absent de la réponse d’un appareil explicitement hors ligne. La présence du relais web reste séparée.

Ces états ne prouvent pas la disponibilité d’une personne ni le nombre d’appels. Après une panne de lecture, les anciens indicateurs instantanés et les commandes de participation aux files disparaissent ; le journal reste consultable. L’attribution des appels traités respecte l’identité utilisée par chaque moteur.

La recette utilise les vraies lectures de l’application et des réponses Asterisk synthétiques sur une base isolée. Aucun téléphone, média ou opérateur réel n’est qualifié. Le protocole V2 dispose désormais de son observation dédiée via le broker de sa cellule.

Les vues carte et tableau montrent ce qui est configuré après le délai de sonnerie de chaque poste, file ou menu vocal. Un transfert conserve son propre délai et son action finale ; la messagerie personnelle termine le parcours. Les données manquantes restent inconnues et produisent une alerte.

Une destination existante de mauvais type ou sans rattachement valide ne produit plus de route verte. Les inventaires et les politiques sont lus au même instant, dans la même organisation. Cette lecture ne prouve pas le résultat d’un appel réel et ne modifie aucun routage.

Conserver une recette par modèle et version : audio dans les deux sens, touches du clavier, transfert direct et accompagné, non-réponse, reconnexion et révocation. Les essais sur le réseau public nécessitent un opérateur et un plan approuvés. Aucun appel improvisé à un service d’urgence pour tester.

La supervision recherche par nom, poste ou compétence, sans être sensible aux accents ou à la casse. Le parcours existe en français, néerlandais et anglais, sur téléphone et ordinateur. Préparer un appel ouvre le combiné avec le poste choisi ; la personne décide ensuite de composer.

Le poste propre et les anciens postes réservés ne proposent pas cette action. Les droits de l’observation courante doivent correspondre au combiné monté dans la page ; sinon une actualisation est proposée. Les numéros publics, urgences et formats ambigus sont refusés entièrement afin de ne pas rouvrir un numéro précédent par erreur.

Les essais utilisent une signalisation simulée. Ils ne qualifient ni la joignabilité d’un collègue, ni le son, ni un téléphone physique. Les contacts externes, favoris et annuaires partagés restent à construire.

Un serveur téléphonique inaccessible affiche « non mesuré », pas zéro appel ou tous les agents hors ligne. Les statistiques du journal et les alertes vocales sont lues séparément. Après une panne, les anciennes mesures restent datées et signalées comme non actualisées ; elles ne sont plus présentées comme un état en direct.

Une seule lecture par source, au plus huit secondes d’attente côté navigateur, puis une nouvelle tentative cinq secondes après sa fin. Les réponses tardives sont ignorées. Si les droits expirent, les deux sources sont arrêtées et leurs données retirées de l’écran.

Onze parcours navigateur ont réussi sur laptop : lenteur, panne, reprise, perte des droits avec réponse concurrente retardée et vraies lectures serveur. Contrôles FR/NL/EN, noms longs et largeurs 320 à 1440 pixels sans débordement ni violation d’accessibilité détectés dans les états testés. Les incidents sont simulés, sans moteur d’appels ni téléphone réel.

Une visite durable commence au moment où le routage entre dans une file. Elle se termine une seule fois par réponse, timeout, abandon, messagerie, transfert, absence de membre routable, échec ou redémarrage. Un appel peut avoir plusieurs visites, y compris après une première réponse ou deux fois dans la même file.

La supervision sépare maintenant les appels réellement en attente, l’attente la plus longue et la moyenne avant réponse. Une visite ouverte avant minuit reste visible après minuit. La moyenne utilise les durées brutes avant un seul arrondi. Les appels du jour restent disponibles séparément comme projection de compatibilité.

Une base sans la migration 0046 continue à router les appels, mais l’écran dit que les temps d’attente ne sont pas mesurés. Il n’utilise jamais le début global de l’appel comme remplacement. Un journal incomplet retire également toutes les valeurs exactes. La base principale du laptop n’a pas été migrée.

Les tests SQLite couvrent réentrée, transfert après réponse, issue terminale unique, ancienne base, passage de minuit, redémarrage, isolation tenant et suppression par rétention. Aucun appel public, téléphone réel, charge ou déploiement cloud n’est prouvé par ce lot.

Un membre peut suspendre ou reprendre sa propre participation depuis la supervision. Le serveur revérifie organisation, file, appartenance, rôle et poste dans la transaction. Le nouvel état et son audit sont enregistrés ensemble. Retirer le membre de la file retire cet état. Un changement temporaire de rôle ou de poste rend la pause dormante sans l’effacer ; elle s’applique de nouveau si l’éligibilité revient, jusqu’à une reprise volontaire et auditée.

Le PBX relit les pauses avant de choisir les candidats d’un nouvel appel et juste avant chaque nouvelle offre round-robin. Une pause enregistrée pendant la première sonnerie empêche donc la suivante. Les anciens membres sans rôle softphone sont exclus. La présence globale reste séparée : un agent peut être connecté et occupé tout en étant en pause pour une file. Une panne de lecture ne transforme pas un état inconnu en agent disponible. Une ancienne base reste compatible, mais l’écran masque les comptes exacts et désactive le contrôle jusqu’à la migration 0047.

La pause ne rappelle pas une offre déjà envoyée et ne coupe pas une conversation. La mutation est bornée à huit secondes et force une relecture après une réponse perdue. La vraie route HTTP a été vérifiée sur une instance jetable migrée, avec pause, relecture, reprise et relecture. Quatorze parcours navigateur passent en FR/NL/EN, de mobile à desktop, sans PBX, appel public ou provider externe.

L’administrateur peut définir de zéro à 3 600 secondes de post-appel pour chaque file. Zéro désactive la fonction. Lorsqu’un membre répond, le PBX conserve durablement dans la visite la file, le membre, le poste, la durée alors applicable et un identifiant de service. La temporisation démarre uniquement lorsque ce membre quitte réellement le service, au raccrochage ou lors d’un transfert qu’il termine.

Un membre en post-appel reste connecté globalement, mais ne reçoit pas de nouvel appel de cette file avant l’heure exacte de fin. Une pause manuelle reste prioritaire. Les transferts aveugles et supervisés conservent le service pour les participants qui continuent la conversation et terminent celui du participant qui quitte l’appel. La fin de chaque service est horodatée dans sa visite avant de modifier le pont ; un transfert supervisé scelle ses sorties ensemble ou n’en applique aucune. Les écritures rejouées sont idempotentes et une fin plus ancienne ne remplace pas une temporisation plus récente.

Une écriture transitoirement impossible est retentée pendant la durée utile et bloque déjà les nouvelles offres dans le processus. Après un redémarrage, seules les visites réellement répondues et terminées sont rejouées, avec leur heure propre de sortie de service plutôt que l’heure globale de fin de l’appel. Un snapshot préparé puis terminé par timeout ne crée jamais de faux post-appel. La supervision ne publie un nombre exact que si la pause, la politique et l’état post-appel sont tous lisibles ; l’état personnel affiche le post-appel au lieu d’affirmer simultanément que l’agent reçoit des appels.

La politique et l’état courant utilisent des tables séparées de la définition de file. Une application mise à jour peut donc encore lire une ancienne base. Sans migration 0048, le routage garde le comportement historique et l’écran retire les nombres exacts au lieu d’afficher zéro. Une panne réelle de lecture après migration ferme la sélection de nouveaux agents pour cette file. Cent cinquante-deux tests ciblés et quinze parcours navigateur passent, dont reprise, rejeu, ordre des fins, pause prioritaire, isolation des organisations, ancienne base, vérité de supervision et affichage FR/NL/EN. Aucun appel public, téléphone réel ou PBX cloud n’a été lancé pour ce lot.

L’administrateur peut définir plusieurs plages par jour, une pause de midi, des dates de fermeture et l’action hors horaires pour chaque file. Une file sans politique reste toujours ouverte. Une ancienne base reste utilisable sans cette fonction et l’écran demande la migration 0049 avant toute configuration.

Le serveur applique les horaires après la résolution d’un menu vocal et avant toute entrée dans la file. Une fermeture vers messagerie ou raccrochage ne crée donc pas de fausse visite de file. Les cibles sont limitées à une messagerie valide de la même organisation. Une ligne incohérente bloque seulement la file concernée, reste visible comme à réparer et ne peut pas être supprimée par une modification sans rapport. Réparer ou désactiver demande un choix explicite.

Les tests ciblés et une validation navigateur manuelle sur une instance isolée couvrent création, plages multiples, changement d’heure, isolation des organisations, ancienne base, corruption, réparation et prévisualisation. Le dépôt ne contient pas encore de scénario Playwright dédié à cet éditeur. Cette preuve concerne la décision déterministe et le banc loopback. Le chemin Asterisk utilise maintenant l’alias opaque de l’utilisateur effectif, y compris lorsqu’un menu vocal fermé redirige vers cet utilisateur, et publie les terminaux utilisateurs du tenant sans exposer leurs numéros. Les files, menus, messageries et réceptionnistes sans exécuteur Asterisk réel sont refusés avant réponse ou média au lieu d’être annoncés comme acheminés. Le dépôt réel d’un message depuis une file fermée reste donc à implémenter et à recetter. Le rappel automatique reste séparé car il crée un appel PSTN sortant soumis à autorité, coût et consentement.

Un nouveau poste conserve sa messagerie personnelle après 30 secondes. Une capacité serveur explicite permet maintenant de sonner les appareils, puis de jouer une annonce approuvée avant de conserver un message chiffré. Le journal distingue une réponse humaine du passage technique à la messagerie. Un refus d'enregistrement ne bloque pas la sonnerie et ne fabrique aucun message.

Le dashboard montre une piste appelant native et distingue publication locale chiffrée et preuve du coffre. Les droits restent liés aux personnes de l'appel après réattribution du poste. La reprise vérifie le reçu et les octets sans recommencer la capture. Dix scénarios intégrés utilisent les vrais composants logiciels avec un Asterisk simulé.

Cette capacité reste désactivée sur le laptop. Les migrations 0053 et 0054 n'ont été appliquées qu'aux bases jetables ; les lectures historiques restent compatibles avec le principal à 41 migrations. Annonce réellement entendue, RTP, téléphones, opérateur et usage client nécessitent encore leurs propres preuves. Les files et boîtes partagées ne sont pas incluses dans ce lot.

Une ancienne réponse ne remplace plus le dernier filtre. Une panne de messagerie n'est plus présentée comme une boîte vide et une panne du journal ne masque plus les messages. Les lectures sont indépendantes, bornées à huit secondes côté navigateur, avec actualisation volontaire. Une perte des droits de consultation retire les données des deux vues.

Les changements « lu/non lu » sont enregistrés avec leur audit dans une même transaction. Une réponse perdue donne un avertissement et une relecture, sans répéter automatiquement l'action. Le rôle support reste en lecture seule ; une ancienne liaison ne permet plus de lire la transcription d'une autre organisation. Un lecteur audio en erreur propose de recharger ; le message ne passe automatiquement à « lu » qu'au démarrage effectif du son.

Vingt-six parcours navigateur réussis, avec incidents et mutations synthétiques, en complément des tests serveur sur une base isolée. Les deux vues ont été contrôlées en FR/NL/EN de 320 à 1440 pixels, sans débordement ni violation d'accessibilité détectés dans les états testés. Ce n'est pas une recette sonore ni un appel réel.

Une panne du module optionnel ne masque plus le journal ni la fiche d'appel. Les données téléphoniques restent consultables ; les relations et décisions sont explicitement « non vérifiées » ou « inconnues ». Après actualisation réussie, les liens reviennent. Une liste vide n'affiche pas d'alerte inutile.

Chaque consultation du contexte VoiceBot est bornée à deux secondes côté serveur, identité et corps de réponse compris. Un filtre de crise peut nécessiter deux lectures successives ; DB et audit ont leur propre coût. Ce n'est donc ni une promesse de réponse totale en deux secondes ni une mesure de latence en production. Les filtres session et incident restent stricts : si leur vérification échoue, ils ne sont pas ignorés.

Trente parcours navigateur réussis pour le journal et la messagerie, avec incidents synthétiques et lectures privées de l'application isolée. Les tests serveur vérifient aussi séparation des organisations, audit obligatoire et reprise d'une preuve d'enregistrement sans doublon. Aucun VoiceBot, PBX, stockage cloud ou modèle IA lancé pour cette validation.

Le journal et la messagerie se consultent par pages de 50 éléments. « Précédente » et « Suivante » conservent les filtres ; un nouveau filtre repart à la première page. « Actualiser » revient aux éléments les plus récents. Modifier l'état lu d'un message conserve la page consultée et suspend sa navigation pendant l'enregistrement.

Le compteur indique les éléments affichés, pas un total historique. Un message sorti de la page après relecture n'est pas déclaré supprimé sans confirmation. Chaque page reste contrôlée par organisation et auditée ; les réponses tardives ne remplacent pas le résultat courant.

Les tests sur base isolée couvrent 112 appels et 112 messages, les limites de page, dates identiques ou absentes, suppression du pivot et insertions. Le curseur fige le calcul des périodes relatives, pas la base de données : rétention, suppressions et arrivées tardives peuvent changer les résultats. Ce parcours n'est ni un export immuable ni une preuve d'exhaustivité historique.

Les sessions VoiceBot sont recherchées par identifiant exact, mais ses incidents proviennent d'une fenêtre de mille sessions récentes, sans signal de troncature dans cette lecture. « Aucun incident retourné » ne prouve donc pas une absence dans tout l'historique.

Le scellement d'enregistrement reste strict : une panne ne fabrique aucune preuve. Une capture déjà conservée peut être reprise sans doublon après la panne, mais la reprise automatique du traitement de messagerie ou du suivi réceptionniste n'est pas encore garantie. Ces traitements demandent une correction séparée.

L'audit actuel sérialise les écritures d'un même processus ; seize lectures concurrentes ont conservé une chaîne valide dans le test isolé. Cela ne qualifie pas un déploiement multi-processus. Mesurer séparément chargement froid, navigation chaude et réponse serveur avant d'annoncer un gain de latence.

Le lanceur a passé 33 tests unitaires et une vérification de démarrage, redémarrage avec données conservées, synchronisation des changements, conflit de port et arrêt ciblé. Huit routes de l’application ont répondu correctement ; la connexion, le dashboard et le menu mobile n’ont présenté aucune violation d’accessibilité détectée par le contrôle automatisé. Aucun débordement horizontal n’a été constaté entre 320 et 1920 pixels.

La bascule de l’ancienne instance est terminée, avec compte et données conservés. Les retours de navigation ont été exercés avec une réponse volontairement retardée : indicateur sans décalage de largeur, interruption par une autre destination, menu mobile et mode mouvement réduit. Le premier chargement en développement compile encore les pages ; ces essais ne donnent pas une mesure de performance en production. Aucun moteur d’appels n’est lancé.

Les pages chargent une seule projection minimale des utilisateurs et postes, puis la donnent à tous leurs formulaires. Elles ne relancent plus une lecture par éditeur. Le navigateur du laptop montre déjà Komer et le poste 6001 au premier rendu des deux pages.

Un poste exige désormais un membre owner, admin ou agent. Une file exige le même type de siège avec un poste utilisateur. Support, opérateur, membre sans poste ou ancien identifiant orphelin ne peuvent pas être ajoutés. S’ils existent déjà dans une file, ils restent visibles comme indisponibles afin que l’administrateur puisse les retirer.

Un utilisateur déjà propriétaire d’un poste n’est plus proposé pour un second poste et les deux routes d’écriture refusent cette liaison. Un doublon historique reste visible comme indisponible pour être réparé ; la supervision le compte comme une seule personne sans ignorer ses anciens endpoints. La migration 0045 prépare l’autorité unique en base et refuse de masquer d’anciens doublons. Elle n’a pas été appliquée à la base principale du laptop.

Les tests ciblés, le typage et l’audit de langue passent. La suite complète reste séparément bloquée par des preuves scellées anciennes, un runtime local Node 22.23.1 face à des laboratoires qui exigent 22.23.2 et des images Docker indisponibles. Ces limites ne sont pas présentées comme un succès du dashboard.

Créer utilisateur, poste, menu vocal, file et destination de secours depuis l’interface ; prévisualiser les effets, appliquer, puis constater le résultat. Tester fermeture, jour férié, absence d’agent et destination supprimée. Les horaires propres aux files disposent maintenant d’un contrat déterministe ; leur exécution Asterisk réelle vers la messagerie et le rappel automatique restent à construire et à autoriser séparément.

Qualifier le matériel, l’opérateur européen, l’hébergement, la sécurité, le support et la reprise après incident. Faire valider le dossier de mise en service par l’autorité compétente du projet. Consulter les preuves et risques et les responsabilités de décision.

La couverture vient de la lecture des pages, API, règles d’accès, contrats d’appareils et tests présents dans le dépôt. L’audit détaillé est conservé dans le document produit navy-phone-gap-audit.md. Une source de code ou un test présent n’est pas une nouvelle exécution réussie.

Aucun appel, achat de matériel, lancement de PBX ou activation cloud n’a été effectué pour cette revue documentaire. Cette page est une référence datée, pas un tableau de santé temps réel ni un second backlog.