Expertise · Téléphonie et centre de contact
Nous construisons le central : trunks SIP, règles de routage par programme, menus IVR lus depuis la base, files d’attente, transfert à un humain, enregistrement et analyse des appels. L’appel devient un enregistrement avec transcript et résumé, pas un souvenir.
Déjà construitTrei implementări proprii, citate mai jos. (1) Stratul Asterisk din platforma Kallina: 5.522 de linii de configurație de dialplan, scripturi AGI și punți audio în `asterisk/`, plus șabloane de trunk generate automat per număr. (2) `asterisk-manager` — un serviciu separat care administrează cozile, trunkurile și fluxul RTP prin interfața de management a centralei. (3) Middleware-ul pentru centrala virtuală a unui operator, care a rulat în producție: commitul de reconciliere din 14 iulie 2026 aduce în depozit cod care rulase pe server și era cu circa 40 de zile înaintea git-ului. Rezerva, spusă înainte să întrebi: gazda SIP prin care trec liniile noastre de test nu răspunde — verificat azi, 06.09.2026, fără răspuns la ping și fără răspuns pe HTTP. Nu prezentăm un număr de demonstrație pe care să suni acum, pentru că nu l-am putea ridica în fața ta.
Entre votre opérateur téléphonique et celui qui répond effectivement — un humain ou un agent vocal — il doit exister une couche qui prend des décisions. Qui reçoit l’appel à 23:40. Que se passe-t-il si personne ne répond. Où va l’appel quand le client demande « un humain ». Ce qu’il reste de la conversation après la fermeture. Cette couche est un central, et nous la construisons pour qu’elle appartienne à l’entreprise, pas au fournisseur de voix : si demain vous changez le moteur de l’agent, les règles de routage, les files d’attente et l’historique restent chez vous.
Concrètement, ce que nous avons construit : douze fichiers de dialplan — production, IVR, file d’attente, transfert, voicemail, renvoi, appels sortants avec agent — quatre scripts AGI en Python et deux ponts audio, soit 5.522 lignes au total. Le moteur IVR n’a pas les menus écrits dans le fichier : il les lit depuis la base via un script AGI et renvoie l’une de six décisions — vers un agent, vers un autre menu, vers une file d’attente, transfert vers un numéro externe, message final, ou fermeture. Les files d’attente portent le nom de leur identifiant et n’ont pas de membres écrits dans la configuration : ils sont ajoutés et retirés de l’extérieur, via l’interface de gestion, ce qui signifie qu’un opérateur peut entrer ou sortir de la file sans redémarrer le central.
Le routage suit des règles réelles, pas un seul « appelez ici » : heures ouvrables et fuseau horaire, plage nocturne du type 22:00 → 06:00, et correspondance par priorité — l’en-tête SIP `Diversion`, qui porte le numéro d’origine depuis lequel l’appel a été redirigé, puis le numéro propre, puis la règle de repli. Les trunks sont générés par numéro, avec un nom construit à partir du fournisseur et du numéro, par une fonction de configuration — pas écrits à la main pour chaque nouvelle ligne.
Ce qui sort de l’appel est tout aussi important que l’appel. Pour la ligne reliée au central virtuel d’un opérateur, nous avons construit un middleware en Python qui interroge la liste des enregistrements toutes les minutes, avec une réconciliation large toutes les six heures afin qu’une panne réseau ne perde rien, et un scan toutes les trois minutes des appels manqués — ceux-ci n’ont pas d’enregistrement et seraient autrement totalement invisibles. Chaque enregistrement est téléchargé, transcrit, analysé et reflété dans l’analyse des appels, et l’appel manqué devient une alerte. L’idempotence repose sur un ensemble Redis, afin que le même enregistrement ne soit pas traité deux fois.
Ce que cela comprend
Les modèles de trunk sont paramétrés et remplis par une fonction de configuration, avec un nom formé à partir du fournisseur et du numéro. Le modèle contient le transport, les codecs autorisés, la gestion du NAT, le mode DTMF et l’authentification. Conséquence pratique : le dixième numéro se connecte comme le premier, et les différences entre opérateurs tiennent en un seul endroit.
Heures ouvrables et fuseau horaire, plage nocturne du type 22:00 → 06:00, correspondance par priorité : l’en-tête SIP `Diversion` (le numéro depuis lequel l’appel a été redirigé), puis le numéro propre, puis la règle de repli. La recherche de la règle se fait par un script AGI qui interroge la plateforme pendant l’appel, avec son propre délai d’attente — donc une règle modifiée dans l’interface s’applique à l’appel suivant, sans redémarrage.
Vers l’agent vocal, l’audio passe par un pont qui convertit le codec dans les deux sens, `g711_ulaw` ↔ `PCM16`. Vers les personnes, l’appel entre dans une file gérée de l’extérieur. Et le transfert est à la portée de celui qui parle : transfert aveugle via `##` et transfert assisté via `*2`, l’appel atterrissant dans un contexte écrit pour cela, qui distingue les extensions internes à quatre chiffres des numéros externes.
Le moteur d’IVR reçoit l’identifiant du menu et le lit depuis la base via un script AGI. Le résultat est l’une de six décisions : vers un agent, vers un autre menu (récursif), vers une file, transfert externe, message final, fermeture. Les messages peuvent être synthétisés ou être des fichiers audio enregistrés à l’avance. Modifier un menu signifie modifier une ligne dans la base, pas éditer un fichier de configuration sur le serveur.
Chaque file porte le nom dérivé de son identifiant. Les membres ne sont pas persistés dans la configuration : ils sont ajoutés et retirés en cours de fonctionnement via l’interface de gestion du central, et la position simultanée sur plusieurs places libres est activée. En pratique, un opérateur entre dans la file ou en sort sans que le central soit redémarré et sans que les appels en attente soient affectés.
Un agent peut appeler lui-même une personne à l’extérieur et revenir avec la réponse. Le mécanisme est implémenté avec une table propre et des états explicites — appel en cours, en cours, à réessayer, terminé, échoué, sans réponse, expiré — avec un maximum de trois tentatives et une pause de deux minutes entre elles, et le résultat (y compris l’heure estimée d’arrivée) est renvoyé de manière structurée vers la conversation qui l’a demandé. Ce n’est pas un concept : ce sont cinq fonctions serveur dédiées, plus un balayage des appels restés bloqués.
Un processus planifié lit la liste des enregistrements toutes les minutes, avec une réconciliation large toutes les six heures afin qu’une panne ne perde rien. L’enregistrement est téléchargé en WAV, transcrit, analysé et reflété dans l’analyse des appels avec l’audio. En parallèle, toutes les trois minutes, les appels non pris sont lus — ils n’ont pas d’enregistrement et n’existeraient autrement nulle part — et deviennent une alerte. Un appel manqué est un client perdu ; le rendre visible est l’amélioration la moins coûteuse dans un centre d’appels.
Le client qui parle avec le central de l’opérateur dispose d’un limiteur de débit propre, avec bucket de jetons, et d’un traitement explicite des erreurs. Ce n’est pas une précaution théorique : un middleware qui interroge toutes les minutes et réconcilie toutes les six heures peut, sans frein, heurter la limite de l’opérateur et être bloqué exactement quand vous en avez besoin.
À quoi cela ressemble
Quels numéros existent, chez quel opérateur, qui répond aujourd’hui sur chacun, dans quel créneau, et ce qui se passe maintenant quand personne ne répond. Cela ressemble à de la bureaucratie ; c’est la partie qui évite les surprises. D’après notre expérience, dans un parc de numéros il existe presque toujours des lignes pour lesquelles la base dit une chose et le central autre chose — et elles ne sont pas découvertes au lancement, mais maintenant.
Le numéro entre sur le trunk, et les appels entrants comme sortants sont testés comme deux choses distinctes, parce qu’elles tombent en panne distinctement. Nous avons documenté un cas où les appels entrants fonctionnaient parfaitement pendant des jours, tandis que tous les appels sortants étaient rejetés par le central de l’opérateur avec `403 Forbidden`, sans aucun changement chez nous. Un seul test « a appelé et ça a marché » ne couvre pas cela.
Les règles d’horaires et de priorité, les menus, les files d’attente et les chemins de transfert sont écrits comme dialplan et comme lignes dans la base, pas comme accord verbal. À la fin, vous savez exactement ce qui se passe avec un appel à 23:40, le samedi, quand l’agent ne comprend pas la demande.
Le résultat de l’appel — transcript, résumé, sentiment, adresse de l’enregistrement, durée — est transmis ensuite via un webhook signé, et l’organisation est identifiée d’après le numéro de téléphone. Là où il existe un CRM, l’appel est lié à la fiche et peut faire automatiquement changer le statut ; nous écrivons à ce sujet sur la page CRM et automatisation des ventes.
Un central sur un seul hôte est un point unique de défaillance, et nous avons vécu exactement cela : quand l’hôte ne répond pas, toutes les lignes qui passent par lui tombent avec lui, quelle que soit la qualité de configuration de l’agent. La signature de la panne est claire — l’appel renvoie « request timed out » avec un identifiant d’appel SIP vide, c’est-à-dire que l’appel SIP ne s’est jamais établi. C’est pourquoi, dans un projet réel, la question « que se passe-t-il quand l’hôte tombe » se pose et se budgétise dès le début : un deuxième hôte, une surveillance qui appelle un humain, et un chemin de secours vers des numéros ordinaires.
Les données
Les questions que pose toute personne ayant un délégué à la protection des données — posées ici avant qu'il ne les pose.
Un cas
La situation
Dans un flux d’analyse des conversations, une partie des appels arrivait en analyse et une partie non. Le schéma a été ce qui a donné la cause : il manquait précisément les appels longs. Un défaut qui se signale comme « parfois ça ne marche pas » et que l’on cherche, à tort, dans la transcription.
Ce que nous avons construit
Il y avait deux voies de transcription et elles tombaient toutes les deux, pour des raisons différentes. La voie multimodale envoie le fichier audio entier encodé dans le corps de la requête ; au-delà d’une certaine taille, la limite de corps du serveur intermédiaire a répondu par 413. La voie de secours demandait un modèle de transcription que la clé d’accès ne permettait plus, donc elle répondait par 403. Les deux échouaient, le processus signalait que tous les modèles de transcription avaient échoué, et l’appel était abandonné. Les appels courts restaient sous la limite de corps, donc passaient — d’où le schéma. La correction a été : on saute la voie multimodale pour les fichiers WAV de plus de 12 MB (seuil configurable depuis l’environnement), on réutilise le transcript déjà calculé au lieu de transcrire une deuxième fois, et la transcription de dernier recours a été déplacée vers un modèle autorisé.
Ce qui en est sorti
Vérifié sur l’enregistrement resté bloqué : une conversation de 21 minutes, fichier WAV de 41 MB — voie multimodale contournée, transcript récupéré, analyse générée, ligne et audio arrivés dans l’analyse d’appels, zéro échec. La réconciliation a ensuite confirmé qu’il n’existe plus d’autres enregistrements bloqués.
Ce que le cas ne dit pas
Le seuil de 12 MB est une propriété du serveur intermédiaire, pas de l’appel. Quand on change de gateway, de clé ou de modèle, le seuil doit être revérifié — c’est pourquoi nous l’avons rendu configurable depuis l’environnement, et non écrit en code.
Questions
Pas aujourd’hui, et nous préférons le dire plutôt que de donner un numéro qui sonne dans le vide. La partie agent peut être écoutée dans la page, immédiatement. La partie téléphone dépend d’un hôte SIP, et l’hôte par lequel passent nos lignes de test ne répond pas à la date d’écriture — vérifié aujourd’hui, sans réponse au ping et sans réponse en HTTP. Pour votre projet, la téléphonie se déploie sur un hôte dédié au projet, pas sur celui de test.
Parce que les règles de routage, les files d’attente, le transfert, la messagerie vocale et l’historique des appels appartiennent à l’entreprise, pas au fournisseur de voix. Avec un central propre, vous pouvez changer le moteur de l’agent sans réécrire le comportement de votre téléphone, vous pouvez envoyer le même appel tantôt à un agent, tantôt à un humain, et vous pouvez garder les traces d’appels chez vous. Sans cela, vous êtes lié à ce que le fournisseur choisit d’exposer.
Toutes les lignes qui passent par lui tombent. Ce n’est pas une hypothèse : c’est ce que nous avons vécu, et la signature est facile à reconnaître — l’appel renvoie « request timed out » avec l’identifiant d’appel SIP vide, donc ce n’est ni la faute de l’agent, ni du numéro, ni du prompt. La conclusion que nous en avons tirée et que nous appliquons désormais à chaque projet : la continuité n’est pas une fonction du central, c’est une décision d’architecture et de budget, prise au début. Cela se résout avec un second hôte et une route de secours vers des numéros ordinaires, pas avec un réglage.
Non. Ce sont deux choses différentes, et l’opérateur peut les traiter différemment. Nous avons documenté un cas où, avec notre configuration inchangée et avec les appels entrants fonctionnels, le central de l’opérateur a commencé à refuser tous les appels sortants avec `403 Forbidden` — la preuve que le problème venait de l’opérateur était qu’un second compte, avec une configuration structurellement identique, continuait à appeler vers l’extérieur. C’est pourquoi nous ne promettons pas une campagne d’appels sortants avant un test sortant réussi sur votre numéro.
Oui, et nous l’avons fait : nous avons écrit un middleware en Python au-dessus de l’API d’un central virtuel d’opérateur, avec client propre, limiteur de débit, téléchargement d’enregistrements, transcription, analyse et alerting, exécuté en production. Ce qu’il faut savoir à l’avance : l’accès à l’API étendue est souvent un service séparé, contracté à part, et les identifiants peuvent ne pas fonctionner du premier coup — chez nous, le cycle de clarification de la spécification et de réinitialisation du mot de passe avec l’opérateur a duré des mois, le service étant déjà facturé. C’est pourquoi, dans une offre qui dépend de l’API d’un opérateur, nous posons explicitement la condition : le travail commence après que l’authentification a été démontrée, pas après qu’elle a été promise.
Ils peuvent être enregistrés, transcrits et analysés. Ils restent liés à l’espace de travail de votre entreprise, et l’accès exige une authentification — il n’existe pas de dépôt commun entre clients. Qui, dans votre équipe, a le droit d’écoute est défini lors de la mise en œuvre. L’annonce à l’interlocuteur et le fondement de l’enregistrement sont vos décisions en tant que responsable du traitement des données ; nous les rédigeons dans le scénario, nous ne les supposons pas.
Ce sont les cas les plus mal traités dans la plupart des entreprises, car ils ne laissent pas de trace : il n’y a ni enregistrement, ni transcript, il n’existe que dans l’historique des appels. Chez nous, un processus lit l’historique toutes les trois minutes, identifie les appels non pris en charge et les transforme en alerte et en ligne visible. Pour être clair sur ce dont cela dépend : nous ne les voyons que dans la mesure où l’opérateur les expose dans son historique.
Oui, et les menus sont stockés dans la base, pas dans des fichiers sur le serveur. Le moteur lit la configuration du menu pendant l’appel et décide d’une des six voies : vers un agent, vers un autre menu, vers une file d’attente, transfert vers un numéro externe, un message final, ou la fermeture. Les messages peuvent être synthétisés ou enregistrés à l’avance. En pratique, un changement de menu ne nécessite pas d’intervention sur le central téléphonique.
Par réconciliation, et c’est une pièce que nous construisons explicitement. La requête rapide dispose d’une fenêtre de quelques dizaines d’heures, et par-dessus celle-ci s’exécute toutes les six heures une réconciliation sur une fenêtre d’une semaine, qui relit plusieurs pages de résultats. Chaque enregistrement traité est marqué, donc la relecture ne duplique rien. Sans réconciliation, une panne d’une heure signifie un trou permanent dans les données — et personne ne le remarque.
22 d'entre elles sont du code et des fichiers de nos dépôts. Nous n'en publions ni le nom ni la ligne : réunies sur une seule page, elles décriraient trop précisément comment sont construits des systèmes qui ne sont pas seulement les nôtres. Nous les parcourons avec vous, dans le dépôt, sur demande — la vérification reste possible, elle se fait simplement lors d'un échange.
Racontez-nous votre processus. Ensemble, nous décidons ce qui vaut la peine d'être construit, ce que nous pouvons connecter et comment nous vérifions le résultat.