Comprendre cette page en 60 secondes
Quatre pannes qui ne restent pas dans un seul domaine: chacune est suivie de son signalement jusqu’à sa réparation, avec la preuve disponible et sa limite.
Résumé essentiel
Quatre scénarios de panne réalistes qui traversent plusieurs parties du service: la perte d’un lieu d’hébergement pendant un appel assisté, la panne du cœur téléphonique local, l’indisponibilité d’un fournisseur extérieur d’intelligence artificielle et la perte de la base de données principale suivie d’une reprise depuis une copie.
Chaque trajet suit les mêmes cinq étapes: comment la panne est détectée, comment elle est contenue, ce que vit l’appelant, comment le service revient et ce qui est réellement prouvé.
Un appel déjà en cours n’est jamais déplacé: si son lieu d’hébergement tombe, il peut être coupé et l’appelant doit rappeler. Les nouveaux appels, eux, sont dirigés vers le second lieu quand c’est possible.
Le logiciel et des essais locaux existent, mais cette page ne prouve pas que le service fonctionne dans un hébergement réel ni sur le réseau téléphonique public. La mise en service reste interdite pour l’instant.
Quatre trajets de panne, étape par étape
Le service est prévu pour deux lieux d’hébergement, appelés A et B. Chaque trajet reste lisible sans fonction interactive: les étapes se parcourent dans l’ordre.
Scénario 1: perte du lieu d’hébergement A pendant un appel avec assistant vocal actif
Une panne qui touche à la fois l’entrée des appels, la voix et l’assistant vocal.
La supervision locale signale que le lieu A ne répond plus; dans les essais, l’alerte est suivie de son déclenchement jusqu’à sa résolution.
Les nouveaux appels sont d’abord proposés à A; en cas de refus explicite ou de silence, ils sont proposés à B. Le lieu fautif est ensuite mis en pause pendant 30 secondes pour éviter les allers-retours.
L’appel déjà en cours sur A, y compris la conversation avec l’assistant vocal, peut être coupé net. Il n’est jamais déplacé vers B.
L’appelant rappelle et son nouvel appel est accepté par B si celui-ci est sain. Un transfert vers un humain reste possible; aucune reprise transparente de l’appel perdu n’est annoncée.
Prouvé localement: le choix A puis B dans un modèle fermé et le suivi complet de l’alerte. Non prouvé: la perte réelle d’un lieu pendant des appels mesurés, avec un opérateur téléphonique réel.
Comment lire ce trajet: avancez avec les flèches du clavier ou parcourez les étapes dans l’ordre.
Étape 1 sur 5: La supervision locale signale que le lieu A ne répond plus; dans les essais, l’alerte est suivie de son déclenchement jusqu’à sa résolution.
Scénario 2: panne du cœur téléphonique local
Le service qui établit et transporte la voix sur place devient indisponible.
Le contrôle de santé retire le cœur téléphonique de la liste des services prêts à accepter un appel; la supervision locale signale l’anomalie.
Toute nouvelle demande d’appel est refusée plutôt que d’accepter une voix mal rattachée au service; aucun chemin de contournement n’est inventé.
Un appel en cours est perdu, avec une cause technique enregistrée; les nouveaux appels sont refusés et l’appelant doit rappeler plus tard.
Le nettoyage local termine proprement les sessions interrompues; dès le retour du service, le parcours vers un humain reste la priorité.
Prouvé localement: le refus ciblé d’un nouvel appel et le nettoyage de session en essai. Non prouvé: la continuité d’un appel actif, la charge réelle et le réseau téléphonique public.
Comment lire ce trajet: avancez avec les flèches du clavier ou parcourez les étapes dans l’ordre.
Étape 1 sur 5: Le contrôle de santé retire le cœur téléphonique de la liste des services prêts à accepter un appel; la supervision locale signale l’anomalie.
Scénario 3: indisponibilité d’un fournisseur extérieur d’intelligence artificielle
Un service extérieur de voix ou de résumé ne répond plus ou est refusé.
La connexion vers le fournisseur extérieur échoue ou est refusée; la réponse attendue n’arrive pas dans le délai prévu.
La connexion sortante concernée est coupée et toute réponse inconnue est refusée; rien n’est envoyé vers un autre fournisseur non autorisé.
La voix de synthèse extérieure ou le résumé automatique devient indisponible; la conversation continue avec une réponse sûre prévue à l’avance ou avec un humain.
Le retour du fournisseur rétablit la fonction. En attendant, aucune action sensible ne progresse et la téléphonie de base reste maintenue.
Prouvé localement: le refus par défaut quand seul le fonctionnement local est autorisé. Non prouvé: le contrat, la résidence des données dans l’Union européenne, la rétention, les quotas et la qualité du fournisseur.
Comment lire ce trajet: avancez avec les flèches du clavier ou parcourez les étapes dans l’ordre.
Étape 1 sur 5: La connexion vers le fournisseur extérieur échoue ou est refusée; la réponse attendue n’arrive pas dans le délai prévu.
Scénario 4: perte de la base de données principale et reprise depuis une copie
La mémoire durable du service est perdue, puis restaurée sous contrôle strict.
La base de données principale ne répond plus; aucune décision durable ne peut plus être enregistrée.
Les admissions et les actions sensibles sont fermées par précaution; l’état des conversations cesse d’avancer plutôt que de risquer une écriture à moitié faite.
Les actions de crise sont bloquées pour éviter un faux enregistrement; l’appelant est orienté vers un humain quand c’est possible.
Une copie est restaurée dans un espace isolé, sous verrou exclusif pour empêcher tout démarrage concurrent; le service reste fermé jusqu’à une décision explicite.
Prouvé localement: 42 essais de reprise isolée et un redémarrage réel qui reste fermé. Non prouvé: les délais de reprise acceptés, une copie représentative et la reprise complète en conditions réelles.
Comment lire ce trajet: avancez avec les flèches du clavier ou parcourez les étapes dans l’ordre.
Étape 1 sur 5: La base de données principale ne répond plus; aucune décision durable ne peut plus être enregistrée.
Les comportements de panne par domaine sont détaillés dans Comportements de panne; la reprise des données suit le flux de Reprise des données.
Preuves locales et limites par scénario
Chaque carte nomme le périmètre exact de la preuve ou de la limite. « Non prouvé » signifie qu’aucune observation acceptée n’autorise l’usage annoncé.
8 gates affichées.
PROUVÉ local Scénario 1: choix A puis B des nouveaux appelsSource: failover carrier
Acquis: le modèle local fermé avance sur 503 ou à 4 s sans réponse, applique le hold-down de 30 s et refuse toute redirection SIP.
Limite: aucun carrier ni PSTN réel ne consomme ces règles sur IP publiques.
PROUVÉ local Scénarios 1 et 2: suivi de l’alerteSource: alerting edge privé
Acquis: le runtime-lab local fermé 12/12 exerce firing vers resolved, déduplication, guérison et deadman stale à 180 s sur 7 endpoints mTLS.
Limite: aucune notification humaine, aucun acquittement ni canal d’astreinte.
PROUVÉ local Scénario 2: refus et nettoyage ciblésSource: comportements de panne
Acquis: la perte simulée de RTPEngine refuse un nouvel appel fail-closed en lab; la perte d’Asterisk ou du bridge termine la session locale avec cause technique et nettoyage.
Limite: la continuité d’un appel actif n’est pas qualifiée et aucune reprise cross-cell n’existe.
PROUVÉ sur snapshot Scénario 4: reprise isolée strict v2Source: reprise des données
Acquis: 126 sources fermées, 48/48 tests recovery dont 42 scénarios hostiles internes, 81/81 sur quatre suites. Tous les drapeaux de test sont refusés hors harnais hermétique et trois SIGKILL sont causalement prouvés.
Limite: l’inventaire vide ne couvre que quatre familles dans le Project et la zone; exclusivité IAM, API publique, vrai Job/provider cloud, perte du contrôleur, RPO/RTO et retour réel du service restent non prouvés. Le vérificateur statique est lexical; un TOCTOU local même UID reste théorique. Essai payant borné GO sous conditions strictes, production NO-GO.
PARTIEL Scénario 3: repli sans fournisseur externeSource: comportements de panne
Acquis: adaptateurs présents et mode LOCAL_ONLY fail-closed; réponse sûre déterministe ou handoff humain quand le modèle est indisponible.
Manque: l’enchaînement complet de bout en bout avec un appel réel et l’audition humaine du repli.
PARTIEL Scénario 4: chaîne de reprise signéeSource: reprise des données, gates P1
Acquis: installation sous autorité, admission fermée par lease exclusif et verrou survivant au reboot.
Manque: release signée, adoption stale et finalizer enchaînés après reboot, et runner CI autorisé.
NON PROUVÉ Scénarios 1 et 2: panne réelle avec appels actifsSource: gates de résilience
Acquis: aucun; le comportement attendu est documenté.
Manque: chaos A/B avec appels actifs mesurés, recette carrier réelle, capacité sous charge et alertes sans flapping.
NON PROUVÉ Scénarios 3 et 4: contrats et objectifs externesSource: comportements de panne et reprise
Acquis: les responsabilités techniques sont nommées par fonction.
Manque: contrat fournisseur, résidence des données dans l’Union européenne, rétention, sous-traitants, SLO, RPO/RTO, PITR, restore candidat production et stockage hors site.
Signaux, premier geste et reprise
Les signaux observés dans les essais locaux, le geste sans risque documenté et l’état de reprise attendu pour chaque scénario.
| Scénario | Signaux | Premier geste | Reprise |
|---|---|---|---|
| 1. Perte de la cellule A, appel assisté actif | Alerte firing sur la chaîne edge-health; absence de réponse ou 503 de la cellule A dans le modèle carrier. | Vérifier que les nouveaux appels basculent bien vers B et que le hold-down de 30 s est actif; ne pas tenter de déplacer un appel établi. | L’appelant rappelle; nouvel appel admis sur B. Le resolved est suivi jusqu’à la guérison; aucune reprise de l’appel coupé. |
| 2. Panne du cœur téléphonique local | Readiness qui retire Asterisk, RTPEngine ou le bridge; alerte firing correspondante. | Constater le refus fail-closed des nouvelles admissions; conserver les causes techniques de fin de session. | Nettoyage local des sessions, puis retour à la readiness; l’appelant rappelle. Continuité d’appel actif non qualifiée. |
| 3. Fournisseur IA externe indisponible | Échec ou refus de l’appel sortant vers ElevenLabs, Anthropic ou OpenRouter; absence de réponse dans le délai. | Vérifier que l’egress concerné est coupé et que le mode LOCAL_ONLY reste fail-closed; ne pas ouvrir un repli réseau non autorisé. | Réponse sûre déterministe ou handoff humain; retour du fournisseur rétablit la fonction. Aucune action sensible ne progresse entre-temps. |
| 4. Perte de la base principale, reprise depuis une copie | PostgreSQL / CAS injoignable; aucun commit décisionnel; admission sensible fermée. | Fermer les actions sensibles; exiger le lease exclusif avant toute restauration; refuser toute archive hostile avant mutation. | Restauration isolée strict v2, finalizer committed-success, service fermé jusqu’à décision explicite des autorités. RPO/RTO non prouvés. |
Déplier ou replier les détails d’architecture
Domaines traversés et dépendances
Chaque scénario compose des modes de panne documentés par domaine; aucun ne crée un comportement nouveau.
| Scénario | Domaines traversés | Dépendances et frontières | État et reprise |
|---|---|---|---|
| 1. Perte de la cellule A | Entrée des appels (cellules carrier), admission A/B, chaîne edge-health, session VoiceBot et pipeline vocal de la cellule. | Le carrier cible non contracté possède la sélection A puis B; redirections SIP interdites; la supervision reste hors chemin d’appel sur le plan management privé. | Aucun état d’appel partagé entre cellules; le dialogue établi reste attaché à sa cellule et n’est pas migré. |
| 2. Cœur téléphonique local | RTPEngine, Asterisk et bridge, media WS / worker, readiness d’admission. | L’admission est fail-closed: aucun média non ancré accepté et aucune route RTP centrale ne contourne la cellule. | Fin de session locale avec cause technique; nettoyage ciblé en lab; reprise cross-cell absente. |
| 3. Fournisseur IA externe | Fournisseurs IA externes, egress firewall, garde déterministe, runtimes STT/TTS locaux de repli. | Coupure de l’egress concerné, refus de toute issue inconnue; les frontières exactes sont dans Frontières de confiance. | Mode LOCAL_ONLY fail-closed; réponse sûre déterministe ou handoff; aucune action sensible ne progresse. |
| 4. Base principale perdue | PostgreSQL / CAS, reprise navy.db strict v2, ledgers d’audit, flux de reprise de Reprise des données. | Lease partagé des services contre lease exclusif de restauration; archive hostile refusée avant mutation; finalizer committed-success. | Aucun commit décisionnel pendant la panne; restauration isolée puis décision explicite; six gates P1 avant toute production. |
Déplier ou replier les détails de sécurité et de preuve
Sécurité, données et souveraineté
Ce que chaque scénario expose, la frontière concernée et la preuve qui manque encore.
| Scénario | Données exposées | Frontière et garde | Preuve manquante |
|---|---|---|---|
| 1. Perte de la cellule A | Média et métadonnées de l’appel actif sur la cellule perdue; alertes content-free seulement côté supervision. | mTLS privé sur le plan management; aucune donnée d’appel dans les enveloppes de santé. | Recette carrier réelle, chaos A/B mesuré, garantie générale de notification unique. |
| 2. Cœur téléphonique local | Enregistrements et messages existants, qui doivent rester protégés pendant l’incident. | Refus fail-closed de tout média non ancré; aucune ouverture du firewall en repli. | Continuité d’appel actif, comportement sous charge, parcours PSTN complet. |
| 3. Fournisseur IA externe | Texte ou audio candidat à l’envoi vers ElevenLabs, Anthropic ou OpenRouter; coupé avant tout repli non autorisé. | Egress borné et LOCAL_ONLY fail-closed; voir Frontières de confiance et Souveraineté des données. | Contrat, résidence des données dans l’Union européenne, rétention, sous-traitants, DPIA et SLO du fournisseur: non prouvés. |
| 4. Base principale perdue | Sessions, configuration, ledgers d’audit et preuves de promotion à restaurer depuis une copie. | Archive hostile refusée avant mutation; restauration en cible isolée sous verrou exclusif. | Backup chiffré séparé, stockage hors site, RPO/RTO approuvés, PITR et restore candidat production: non prouvés. |
Décision actuelle: promotion NO-GO, pas de mise en production. Les scénarios combinent des preuves locales nommées; aucun n’est exercé de bout en bout sur un hébergement réel, un carrier ou le PSTN. Blockers: recette carrier, chaos A/B, contrats et résidence des fournisseurs, objectifs RPO/RTO, restore candidat et attestation externe restent des gates ouvertes.
Pages voisines: Comportements de panne par domaine · Reprise des données · Frontières de confiance · Souveraineté des données.