Il y a quelques jours, je présentais Greywall — un sandbox kernel-level qui contient pi grâce à une approche deny-by-default. C’est votre mur extérieur. Mais qu’en est-il des menaces à l’intérieur de la frontière ? L’agent qui écrit accidentellement dans le mauvais projet, le fichier .env qui se retrouve dans le contexte LLM, le skill dont le SKILL.md a été silencieusement modifié. C’est un problème différent, qui nécessite un outil différent.
Bonjour, je suis Mathias 👋
Salut ! C’est ici que je partage mes pensées et mes notes sur tout ce qui me passionne et sur lequel je bosse en ce moment. J’espère vraiment y rencontrer des gens qui pensent comme moi. Salut ! Je voulais juste te dire que… J’aimerais vraiment avoir de tes nouvelles !
Je t’invite à jeter un œil à mes derniers articles de blog, juste en dessous.
Les agents de code IA comme pi sont devenus des compagnons indispensables au quotidien. Mais par défaut, pi fonctionne en mode YOLO : accès complet au filesystem, exécution de n’importe quelle commande, aucune restriction. C’est un choix délibéré de son créateur, mais cette liberté a un coût réel. Aujourd’hui, je vous propose de découvrir Greywall, un outil qui permet de sandboxer pi grâce à une approche deny-by-default au niveau kernel.
Dans le contexte actuel où les architectures télécom évoluent vers des solutions cloud-native et microservices, la flexibilité du routage SIP devient un enjeu majeur. Kamailio, en tant que serveur SIP puissant et modulaire, propose des modules comme http_async_client et rtjson qui permettent d’intégrer facilement des décisions de routage dynamiques basées sur des réponses de microservices externes.
Présentation des modules Kamailio
http_async_client
Le module http_async_client permet d’effectuer des requêtes HTTP(S) de manière asynchrone, sans bloquer le traitement des messages SIP. Cela signifie que Kamailio peut interroger un service externe (API REST, microservice) pour obtenir des instructions de routage, tout en continuant à gérer d’autres appels.
Les Call Detail Records (CDR) constituent une source d’information cruciale pour les opérateurs télécoms et les entreprises : ils retracent chaque appel, sa durée, ses participants, l’heure, la localisation, etc. Mais face à la volumétrie croissante de ces données, l’intelligence artificielle s’impose comme un allié incontournable pour extraire des insights à forte valeur ajoutée.
Pourquoi analyser les CDR avec l’IA ?
Traditionnellement, l’analyse des CDR permettait surtout la facturation et la détection de fraudes. Aujourd’hui, l’IA permet d’aller beaucoup plus loin :
Dans la continuité de mon précédent article sur l’IA dans les télécoms d’entreprise, je vous propose aujourd’hui de plonger dans un cas concret : la mise en œuvre d’un workflow automatisé pour transformer la voix en texte grâce aux APIs de Wazo et Modjo.
Pourquoi automatiser la retranscription des appels ?
La transcription automatique des appels permet :
- d’analyser finement les échanges clients,
- de faciliter l’archivage et la recherche de conversations,
- de gagner du temps sur la gestion documentaire,
- et d’améliorer la conformité réglementaire.
Ce processus s’avère particulièrement utile dans les centres de contact, le support client ou le suivi commercial.
À l’heure où la compétition dans les télécoms est plus féroce que jamais, l’intelligence artificielle s’impose comme un moteur de transformation incontournable. Que ce soit pour la supervision des réseaux, l’analyse des données ou encore l’automatisation des processus, l’IA offre des avantages opérationnels et stratégiques indéniables.
L’IA dans la supervision des réseaux : une vigie en temps réel
Les systèmes de télécommunications deviennent de plus en plus complexes. Grâce à l’IA, il est possible de détecter des anomalies réseau avant même qu’elles n’affectent les services. En analysant des millions de signaux en temps réel, les algorithmes peuvent alerter les équipes techniques et ainsi réduire drastiquement les temps d’arrêt et les perturbations. Cela se traduit par une meilleure continuité de service, et donc une satisfaction accrue des clients.
Le routage d’appels selon le CallerID permet d’adapter dynamiquement le traitement des appels entrants en fonction du numéro de l’appelant. Cette technique est particulièrement utile pour traiter différemment certains clients, partenaires, ou encore pour gérer des scénarios spécifiques comme le routage des appels internationaux vers une destination dédiée.
Dans cet article, nous illustrons cette approche en configurant le routage des appels internationaux avec Asterisk et Wazo, en tenant compte du fait que le préfixe + du format E.164 est généralement supprimé avant l’entrée dans le dialplan.
Les regex sont des outils très puissants pour valider des formats et extraire des parties de chaines de caractères. Voici une regex très utile dans le domaine de la téléphonie permettant de valider si le numéro appelé ou présenté respecte le format internationnal E.164 :
^\+[1-9][0-9]{5,14}$
Voici un exemple d’utilisation en langage Rust :
// include the latest version of the regex crate in your Cargo.toml
extern crate regex;
use regex::Regex;
fn main() {
let regex = Regex::new(r"(?m)^\+[1-9][0-9]{5,14}$").unwrap();
let string = "+3390123456789";
// result will be an iterator over tuples containing the start and end indices for each match in the string
let result = regex.captures_iter(string);
for mat in result {
println!("{:?}", mat);
}
}
et en golang :
Un serveur STUN est utile dans le processus de découverte de l’adresse IP publique à la fois pour les terminaux SIP mais surtout les applications WebRTC.
Le WebRTC nécessite une connexion directe entre les pairs, mais souvent une connexion directe ne peut pas être établie notamment à cause du NAT et un serveur TURN est donc nécessaire.
Dans cet article, nous allons expliquer comment vous pouvez exécuter votre propre serveur STUN/TURN en utilisant l’implémentation du serveur STUN/TURN open source, c’est-à-dire Coturn.
Défini en 2013 par la RFC6844, le CAA est un type d’enregistrement DNS qui permet aux propriétaires de sites de préciser quelles autorités de certification (CA) sont autorisées à émettre des certificats contenant leurs noms de domaine.
Quel est l’intérêt
Par défaut, chaque autorité de certification publique est autorisée à émettre des certificats pour tout nom de domaine dans le DNS public, à condition qu’elle valide le contrôle de ce nom de domaine.
