Blog
Analyses techniques et réglementaires de l'équipe DalonCorp : Voice AI souveraine, conformité européenne, télécoms et architectures temps réel.
L'opérateur historique ferme ses commutateurs RTC, à une échéance qui ne sera pas repoussée. Ce n'est pas une migration technique facultative : c'est un déplacement de tout votre flux vocal. Voici la checklist que nous utilisons en AMO, dans l'ordre où les décisions doivent être prises.
Pourquoi la pression est réelle
Le RTC (Réseau Téléphonique Commuté) disparaît pour des raisons économiques et techniques : moins d'abonnés, coûts de maintenance des commutateurs en hausse, et le SIP a gagné la bataille technique il y a dix ans. Les opérateurs annoncent des dates de fermeture par zone, et l'agenda glisse plus vite que prévu pour les entreprises : quand votre agence bascule, les flux entrants vers vos sites RTC restants se raréfient.
Migrer n'est pas une option parmi d'autres : c'est un rendez-vous. La question est de savoir si vous le prendrez dans des conditions maîtrisées, ou en urgence quand la date tombe.
Phase 1, L'audit (la moitié du travail)
Avant tout choix technique, cartographier :
- Inventaire du parc RTC existant : nombre de lignes, sites, usages (fax ? alarmes ? ascenseurs ? lignes bancaires dédiées ?), le RTC traîne toujours des services auxquels personne ne pense plus
- Recensement des flux : entrants, sortants, numéros spéciaux, SDA (Sélection Directe à l'Arrivée)
- Qualité des liens actuels : débit, jitter, perte, la migration est aussi l'occasion de réviser les accès
- Les applications cachées : autoradio de site, interphonie téléguidée, modems legacy, c'est là que les migrations échouent
- La dépendance à l'opérateur : contrats, échéances, clauses de sortie
Phase 2, Choisir le mode de connexion
| Mode | Quand le choisir | Points d'attention |
|---|---|---|
| Trunk SIP opérateur | Vous voulez externaliser la voix | SLA opérateur, QoS de bout en bout, portabilité des numéros |
| Trunk SIP inter-site privé | Vous maîtrisez plusieurs sites | Qualité du WAN, redondance des liens |
| Hybride RTC + SIP (transitoire) | Migration par phases | Cohabitation des deux mondes, prévoir la passerelle |
Le choix dépend de votre dispersion géographique, de votre tolérance au risque et de votre échéancier. Règle empirique : ne jamais basculer un site entier sans période de coexistence, les deux mondes doivent tourner en parallèle jusqu'à la validation complète.
Phase 3, La technique (où les projets échouent)
Le SBC (Session Border Controller)
Non négociable :
- Sécurisation : chiffrement SIP/TLS et média (SRTP)
- Interworking : adaptation des codecs entre votre IP PBX et l'opérateur
- Topologie cachée : votre plan d'adressage interne n'apparaît pas sur le réseau opérateur
- Protection DoS/fraude : la frontière SIP est une porte d'attaque majeure (les fraudes télécoms coûtent des millions)
Le plan de numérotation
Le piège classique : votre IP PBX avait ses règles de numérotation interne, l'opérateur a ses formats. Il faut une table de correspondance complète, chaque numéro externe, chaque extension, chaque cas de routage. C'est fastidieux, c'est critique, c'est là que les appels se perdent.
Les codecs
- Audio : G.711 (compatibilité universelle) vs G.729/Opus (bande passante), le choix impacte le dimensionnement WAN
- Transcodage : si votre SBC doit transcoder, il consomme du CPU, sous-estimé systématiquement
- Fax (T.38) : si vous en avez encore, c'est le point le plus fragile de la migration
La qualité de service (QoS)
- Priorisation des flux temps réel : RSVP ou DSCP sur votre WAN
- Dimensionnement : calculer Erlang (nombre de canaux simultanés), pas le nombre d'employés
- Supervision : MOS, jitter, perte de paquets, mesurable avant engagement final
Phase 4, La migration progressive
Le scénario éprouvé :
1. Site pilote : un site de petite taille, peu critique, apprendre sur du réel 2. Coexistence totale : RTC et SIP tournent en parallèle, le plan de numérotation est doublé 3. Basculements progressifs : par service, par ligne, pas tout d'un coup 4. Période de recette : tests d'appels entrants ET sortants vers tous les types de destination (mobiles, RTC restant, internationaux, urgents 112) 5. Résiliation RTC : seulement quand toutes les exceptions sont traitées (fax, alarmes, modems)
Phase 5, Sécuriser le nouveau monde
Le trunk SIP change la nature du risque : vous n'êtes plus derrière une commutation opérateur, vous êtes un point d'entrée réseau.
- Chiffrement SIP/TLS + SRTP : la signalisation et le média
- Anti-fraude : la fraude télécom (toll fraud) coûte des milliards, surveillance des appels sortants anormaux
- Protection DoS : les SBC sont les cibles privilégiées, un AAGuard devant votre infra ne fait pas de mal
- Conformité : registre des communications, rétention réglementée selon votre secteur
Et l'IA vocale dans tout ça ?
C'est LA raison de faire la migration correctement : le trunk SIP est la porte d'entrée de votre Voice AI. Un appel arrivant en SIP peut être routé vers un agent vocal qui transcrit, comprend et répond via le pipeline complet. Un RTC ne peut pas brancher un LLM.
La migration SIP n'est donc pas seulement un coût réglementaire : c'est l'activation de la couche Voice AI de votre service client. Les entreprises qui feront la migration proprement en 2026 auront l'infrastructure pour brancher un assistant vocal en 2027 ; les autres migreront deux fois.
Checklist de synthèse
- [ ] Audit flux + applications cachées (fax, alarmes, modems)
- [ ] Choix du mode (opérateur / inter-site / hybride)
- [ ] SBC dimensionné (codecs, transcodage, DoS)
- [ ] Table de correspondance numérotation complète
- [ ] Plan de migration par phases avec coexistence
- [ ] Tests de recette complets (urgents inclus)
- [ ] Sécurité : TLS, SRTP, anti-fraude
- [ ] Supervision QoS (dashboard, alertes)
- [ ] Plan de retour arrière documenté
- [ ] Prévision Voice AI : port SIP → agent vocal
Pour aller plus loin
- Notre formation : Maîtriser la migration vers le trunk SIP, 5 modules, travaux pratiques, cas réels
- L'AMO DalonCorp, nous pilotons la migration, vous gardez la maîtrise
- Le pipeline vocal, ce que le SIP débloque ensuite
Second volet de notre série réglementaire, après « Pourquoi le cloud US est un choix réglementaire ». Ici : ce que l'AI Act exige concrètement d'un RSSI qui déploie de l'IA, et comment s'y préparer sans y passer ses nuits.
La chronologie à retenir (et déjà en cours)
L'AI Act (règlement UE 2024/1689) est entré en vigueur le 1er août 2024. Ses obligations s'appliquent par vagues :
| Date | Ce qui commence à s'appliquer |
|---|---|
| 2 février 2025 | Interdictions (usages IA prohibés) + littératie IA (obligation de former les utilisateurs) |
| 2 août 2025 | Règles GPAI (modèles à usage général), gouvernance, sanctions |
| 2 août 2026 | Le gros morceau : obligations systémiques des systèmes à haut risque (annexe III) |
| 2 août 2027 | IA haut risque embarquée dans des produits réglementés (annexe I) |
Ce qui compte pour un RSSI en 2026 : tout ce qu'il faut avoir en place avant le 2 août 2026, c'est-à-dire maintenant.
La classification : où votre cas d'usage se range
L'AI Act classe les systèmes d'IA en 4 niveaux. Pour une plateforme Voice AI, la grille est :
| Niveau | Exemple Voice AI | Obligations |
|---|---|---|
| Interdit (risque inacceptable) | IA qui note les émotions au travail, scoring social | Exclu, DalonCorp n'en expose aucun |
| Haut risque (annexe III) | IA de tri de CV, scoring crédit, biométrie à distance légale | Obligation lourde (évaluation conformité, logs, supervision humaine) |
| Risque limité | Chatbots, assistants vocaux grand public | Transparence : l'utilisateur doit savoir qu'il parle à une IA |
| Minimal | Filtrage anti-spam, aide contextuelle métier | Code de conduite recommandé |
Le point de vigilance n°1 : la transparence. Si votre assistant vocal parle à un humain sans qu'il le sache, vous êtes en infraction dès août 2025 (obligation déjà entrée en vigueur). L'accueil vocal doit s'identifier comme IA, c'est un paramètre de configuration, pas une option.
Les obligations du fournisseur vs du déployeur
L'AI Act distingue deux rôles, et vous êtes souvent les deux :
Le fournisseur (qui développe le système) doit :
- Documenter le modèle (technical documentation)
- Implémenter la gestion du risque
- Garantir la qualité et la gouvernance des données
- Journaliser (logs automatiques)
- Fournir l'information aux déployeurs
- Concevoir pour la supervision humaine
Le déployeur (vous, l'entreprise qui le déploie) doit :
- Utiliser le système conformément aux instructions
- Assigner la supervision humaine à des personnes compétentes (littératie IA)
- Garantir la qualité des données d'entrée
- Journaliser et conserver les logs
- Informer les utilisateurs (transparence IA)
- Pour les systèmes à haut risque : évaluer l'impact (DPIA au sens RGPD, souvent complémentaire)
La bonne nouvelle pour les déployeurs DalonCorp : le rôle fournisseur est notre responsabilité contractuelle. L'architecture on-premise vous donne, en revanche, le contrôle total des logs, donc la capacité de démontrer la conformité (les obligations de journalisation sont les vôtres en tant que déployeur, et vos données restent chez vous).
Ce que le RSSI doit mettre en place, concrètement
1. L'inventaire des systèmes IA (inventaire existant ≠ inventaire AI Act)
Listez tous les systèmes qui utilisent de l'IA générative dans votre SI (y compris SaaS tiers et copilotes embarqués). Pour chacun : quel niveau de risque ? Quelles données traitées ? Qui supervise ?
2. La journalisation (article 12)
Toute plateforme à haut risque doit journaliser automatiquement : identifiants, horodatages, contextes d'entrée, comportements du modèle. C'est exactement le rôle de l'audit log DalonCorp : chaque conversation, chaque tool call, chaque détection AAGuard est tracée avec son identité NSC.
3. La littératie IA (article 4, déjà applicable)
Depuis février 2025, vous devez garantir que les utilisateurs de vos systèmes IA ont la formation nécessaire. Une formation IA de base est donc déjà une obligation, pas un bonus. Nos programmes couvrent ce socle.
4. La transparence de bout en bout
- L'utilisateur doit savoir qu'il parle à une IA
- Vous savez quel modèle tourne, sur quel GPU, avec quelles données (Ollama on-prem, pas de boîte noire)
- Chaque décision du système est tracée et explicable
5. La supervision humaine
L'agent vocal doit pouvoir passer la main : escalade vers un humain, circuit de réclamation, possibilité de contester une décision automatisée. Dans la plateforme DalonCorp, le transfert vers un agent humain est un tool natif, pas un développement spécifique.
Le bonus sous-estimé : une conformité RGPD déjà en place
Le gros de la préparation AI Act pour un déployeur recoupe le RGPD :
- DPIA : analyse d'impact, déjà obligatoire pour les traitements sensibles
- Journalisation : déjà exigée par NIS2 et DORA dans les secteurs régulés
- Supervision humaine : déjà exigée par le RGPD pour les décisions automatisées (art. 22)
- Minimisation des données : l'argument on-premise, pas de données qui sortent, donc pas de DPIA sur les transferts
Si vous êtes déjà conforme RGPD sur votre infrastructure, l'AI Act est une extension de votre dispositif existant, pas un chantier de fond. La différence : il faut maintenant documenter le système d'IA spécifiquement.
Checklist de préparation (à télécharger)
Au niveau gouvernance
- [ ] Inventaire des systèmes IA (SaaS inclus !)
- [ ] Classification par risque (interdit / haut risque / limité / minimal)
- [ ] Désignation d'un responsable IA (ou extension du rôle du RSSI)
- [ ] Programme de littératie IA pour les utilisateurs
Au niveau technique
- [ ] Logs conversationnels complets (qui, quoi, quand, quel modèle)
- [ ] Transparence IA pour tous les canaux (voice, chat, email)
- [ ] Mécanisme de supervision humaine (handoff agent → humain)
- [ ] Capacité de démonstration du chemin de conformité (spec → code → logs)
Questions à poser à vos fournisseurs d'IA 1. Où tourne l'inférence, physiquement ? (Si réponse SaaS : quelle juridiction ?) 2. Quel modèle exact tourne-t-il ? (Version figée ? Mise à jour silencieuse ?) 3. Avec quelles données ? (Y a-t-il entraînement sur mes données ?) 4. Où sont les logs ? Combien de temps ? Qui y accède ? 5. Comment l'utilisateur sait-il qu'il parle à une IA ?
---
Ce ne sont pas des notes juridiques, mais une grille de lecture technique depuis l'expérience d'opérateur de plateforme. Pour l'interprétation juridique de votre cas, votre DPO reste la référence.
Pour aller plus loin
- La sécurité DalonCorp de bout en bout, les 5 couches techniques qui servent la conformité
- Notre positionnement, la Voice AI souveraine pour l'Europe
- Le texte intégral : REGULATION (EU) 2024/1689, AI Act
- Télécharger la proposition de valeur (PDF)
Un article à destination des DSI et RSSI qui évaluent une solution Voice AI en 2026. Les textes cités sont réels ; les implications sont les nôtres.
Le scénario qui inquiète chaque RSSI (et devrait)
Un hôpital européen déploie un assistant vocal pour ses équipes : transcription automatique des consultations, notes dans le dossier patient. Le produit retenu est excellent, l'intégration est rapide, le contrat signé mentionne « données stockées en UE ».
Puis une question tombe lors de l'audit : quel prestataire héberge le fournisseur ? Et surtout : de quelle nationalité est le fournisseur ?
Parce que si ce fournisseur relève du droit américain, la réponse au RSSI est inconfortable : ses données peuvent être réquisitionnées par les autorités américaines, sur la seule base des lois US, sans que l'hôpital ne soit informé, et quelle que soit la localisation des serveurs.
Trois lois, une même extraterritorialité
USA PATRIOT Act (2001)
Le plus ancien et le plus large. Il autorise l'accès aux dossiers, y compris ceux détenus par des entreprises détenues ou contrôlées par des intérêts américains, où qu'ils soient. Une filiale européenne d'un éditeur US est concernée. Le secret (gag orders) empêche l'entreprise de vous prévenir : vous ne saurez jamais.
CLOUD Act (2018)
Le complément décisif : il explicite que le Patriot Act s'applique indépendamment du lieu de stockage. Vos données sont en Irlande ? Sur un GDS européen ? Peu importe : si l'éditeur est américain, ses serveurs dans le monde sont accessibles par mandat. C'est la règle de l'extraterritorialité du prestataire, pas du serveur.
FISA §702 + EO 12333
Le FISA (Foreign Intelligence Surveillance Act) cible les « non-US persons », précisément vos utilisateurs européens. L'Executive Order 12333 étend les capacités hors cadre judiciaire. Ces textes ne s'appliquent pas seulement aux « suspects » : le volume collecté est massif, la surveillance de masse documentée.
Ce que les contrats ne changent pas
Beaucoup de DSI croient se couvrir avec des clauses. Trois rappels :
1. Les Data Privacy Framework (DPF) et SCC couvrent le transfert au sens RGPD, pas la loi d'accès US. L'éditeur n'a pas le droit de vous remettre vos données à une autorité US ; il peut légalement être obligé de le faire sans vous en parler. 2. Le CLOUD Act prévoit même des accords bilatéraux qui court-circuitent l'avis, la jurisprudence évolue, dans le sens d'un accès plus large, pas plus restreint. 3. La CJUE (arrêts Schrems I et II) a invalidé plusieurs cadres de transfert exactement pour cette raison : le droit US n'offre pas un niveau de protection équivalent. Se défier du serveur ne suffit pas ; il faut se défier du contrôle.
Alors, quelles options pour un RSSI ?
| Option | Ce que ça règle | Ce que ça ne règle pas |
|---|---|---|
| Clause contractuelle renforcée | Responsabilité contractuelle | L'accès légal US reste possible (le droit prime) |
| Fournisseur UE filiale d'un groupe US | Hébergement EU | Le lien de contrôle remonte au siège (CLOUD Act le vise) |
| Open source audité, hébergé on-prem | Aucune juridiction US applicable | Vous gérez l'infrastructure |
| On-prem + modèles open source (Ollama) + GPU locaux | Tout ce qui précède + coût plafonné | Un CAPEX (GPU), et c'est tout |
La troisième option est celle qu'exigent déjà la santé, la finance et la défense. Le reste du marché la découvre.
Et la Voice AI dans tout ça ?
La Voice AI agrège les données les plus sensibles qui soient : la voix (biométrique), les transcriptions (contenus de pensée reformulés), les prompts (intentions, contextes privés), et souvent les identités des interlocuteurs. C'est exactement le type de données qui, une fois réquisitionnées, ne peut pas être « rendue ».
C'est pourquoi DalonCorp ne prône pas un « cloud européen » de plus, la question n'est pas la localisation du disque, mais le cadre juridique qui s'y applique. Notre plateforme Voice AI tourne chez vous, sur vos serveurs, avec l'inférence sur vos GPU (Ollama) et l'identité cryptographique locale (NSC, Ed25519).
- Mode on-premise : aucun octet ne quitte votre infrastructure. Pas de DPF à signer. Pas de question FISA à se poser. Schrems II ne s'applique même pas, il n'y a pas de transfert.
- Cloud offloading maîtrisé : quand une charge non sensible peut tourner dans le cloud (marges, prototypage), elle y va, et revient on-prem quand le volume ou la réglementation l'exige. Sans réécrire une ligne de code.
Ce qu'il faut retenir
1. La localisation du serveur ne protège pas : c'est la nationalité du fournisseur qui compte (CLOUD Act). 2. Les clauses se défient mutuellement : un DPF ne neutralise pas le Patriot Act. 3. La seule architecture qui neutralise ces lois est celle où le fournisseur n'a pas vos données. C'est toute la thèse de DalonCorp.
Pour aller plus loin
- Le positionnement DalonCorp, la Voice AI souveraine pour l'Europe
- La sécurité de bout en bout, les 5 couches defense-in-depth
- Télécharger la proposition de valeur (PDF)