47 jours. Le compte à rebours a commencé.
En mars 2029, les certificats publics passent à 47 jours de validité. Pour vos SBC, c'est huit renouvellements par an au lieu d'un. Sans interruption de service. Sur tout votre parc.
Ce qui change en mars 2029
Le CA/Browser Forum a acté une réduction progressive de la durée de validité des certificats publics, jusqu'à un plafond de 47 jours à partir de mars 2029. Concrètement, ce qui se renouvelait une fois par an doit désormais être renouvelé huit fois par an. Sur des dizaines, parfois des centaines d'équipements.
Pour les infrastructures voix — SBC, trunks SIP, frontaux d'enregistrement — le risque est direct : un certificat oublié, c'est une panne télécom P1. Et le sujet se joue à l'intersection des équipes PKI et télécom, avec des outillages et des cycles de vie historiquement pensés séparément.
Les plateformes en première ligne, ce sont celles que tous les décideurs ont en tête : Microsoft Teams (via Direct Routing), Genesys Cloud, et plus largement les services de communications unifiées et les centres de contacts cloud. Tous reposent sur des SBC qui présentent des certificats publics aux opérateurs et aux services cloud. Chaque renouvellement raté, c'est un trunk qui tombe.
Aujourd'hui, les outils PKI d'entreprise ne dialoguent pas nativement avec les SBC. Les scripts maison meurent avec leur auteur. La plupart des grands comptes ne sont pas prêts.
La trajectoire CA/Browser Forum
Hier
398 jours
15 mars 2026
200 jours
15 mars 2027
100 jours
15 mars 2029
47 jours
Le workflow
Certificate Automation Bridge est un module de SIPify Pulse. Il fait une chose, et il la fait bien : industrialiser le cycle de vie des certificats sur les infrastructures voix, sans intervention humaine, sans interruption de service.
Inventaire automatique
Découverte des certificats déployés sur tout le parc SBC, par équipement, par interface, par usage.
Audit pré-renouvellement
Vérification de la compatibilité algorithme, chaîne de confiance, dates d'expiration et dépendances avant toute action.
Orchestration bout-en-bout
Génération de la CSR, soumission à l'autorité, déploiement sur l'équipement, rollback automatique en cas d'échec.
Post-checks fonctionnels
Tests d'appel après bascule. On ne valide pas qu'un fichier est en place, on valide que la voix passe.
Journal d'audit conforme
Qui, quand, quoi. Sortie prête pour les équipes RSSI et le contrôle interne.
Script interne vs CAB
Pourquoi un module produit, plutôt qu'un script maison
| Script interne | CAB |
|---|---|
| Écrit par un expert qui finit par partir | Maintenu et versionné par SIPify, support N1 NXO |
| Mono-technologie ou mono-version | Multi-technos SBC, agnostique constructeur |
| Pas de rollback, pas de post-check | Rollback automatique + tests d'appel post-bascule |
| À refaire à chaque montée de version SBC | Mises à jour produit livrées par l'atelier SIPify |
| Conformité non démontrable | Journal d'audit prêt pour RSSI / contrôle interne |
CAB n'est pas un produit de roadmap. C'est un workflow que l'on a codé pour répondre à un besoin concret.
SIPify Pulse, c'est l'atelier agile de la voix. Une équipe d'experts VoIP, une usine à code augmentée par l'IA, et la capacité de transformer un besoin métier en automatisation livrée en quelques semaines — pas en deux ans.
Là où les gros éditeurs poussent des plateformes génériques avec des roadmaps figées, on part du workflow client. AutoDialer, Traffic Guardian, SBC Config Utility, CAB : ce ne sont pas des produits, ce sont les premiers workflows sortis de l'atelier. Le prochain peut être le vôtre.
Distribué par NXO
SIPify Pulse est distribué en exclusivité par NXO, intégrateur grands comptes. Équipe commerciale dédiée, support N1 formé, déploiement industriel sur les infrastructures sensibles. L'agilité d'un atelier, la solidité d'un grand groupe.
Questions fréquentes
Combien de temps prendrait ce workflow chez vous, avec votre éditeur actuel ?
Démo personnalisée sur votre périmètre SBC. 30 minutes. Aucune installation préalable.
Vous pouvez aussi passer par votre contact NXO habituel.