Blog

Quatrième volet de la série verticale. Ici : la finance, un secteur doublement contraint : la conformité interdit le cloud, et la menace exige l'IA.

La menace qui a changé d'échelle

La fraude vocale n'est plus l'affaire d'un imitateur au téléphone. Depuis l'arrivée du clonage vocal (quelques secondes d'audio suffisent), les cas documentés se multiplient : faux ordres de virement autorisés par la voix d'un dirigeant, usurpation dans les centres de relation client, contournement de l'authentification vocale elle-même.

Confrontées à cette menace, les banques ont besoin de deux choses simultanément :

1. Analyser les appels entrants et sortants (détection de fraude, conformité des conversations, coaching des agents) 2. Automatiser une partie du service vocal (assistance, information, qualification)

Or chacune de ces deux exigences se heurte au même mur : l'analyse d'un appel bancaire exige de traiter des données réglementées, parfois des données de carte (PCI-DSS), toujours des données personnelles et financières, très souvent du contenu couvert par le secret professionnel bancaire.

Le double réglementaire : DORA et PCI-DSS

DORA (Digital Operational Resilience Act, en application depuis janvier 2025)

Le règlement européen de résilience opérationnelle du secteur financier impose, entre autres :

• Maîtrise des risques tiers : tout prestataire ICT est cartographié, ses risques évalués, un cloud US est un fournisseur critique dont l'acte de réquisition (Patriot Act, CLOUD Act) devient votre risque de non-conformité
• Continuité d'activité : la plateforme doit survivre à la panne d'un tiers, une dépendance à un cloud tiers qui peut tomber est contraire à la philosophie DORA
• Tests de résilience : possible quand l'infrastructure est la vôtre, délicat quand elle est partagée

PCI-DSS (paiement)

Dès qu'une conversation bancaire peut contenir des données de carte (panique de l'appelant qui récite son numéro), la plateforme d'enregistrement et d'analyse entre dans le périmètre PCI-DSS, 12 exigences, des audits annuels (QSA), des coûts de conformité non triviaux sur toute solution tierce qui touche ces données.

La conséquence mathématique : chaque fournisseur SaaS supplémentaire dans le périmètre (STT cloud, LLM API, TTS cloud) est un audit de plus, un contrat PCI de plus, un risque de plus.

La fraude vocale elle-même

Le clonage vocal n'est plus de la science-fiction : des cas documentés montrent des arnaques au « fake CEO » et l'usurpation de clients pour autorisations de virement. Une banque a besoin de détecter ces tentatives, et la détection passe par l'analyse des flux vocaux, donc par le même périmètre de données sensibles.

Ce que l'on ne peut pas faire dans le cloud US (et ce qu'on peut faire on-prem)

Action	Cloud US	On-prem DalonCorp
Enregistrer et transcrire les appels clients	⚠️ Données bancaires transmises à un tiers US	Whisper sur vos GPU, local
Analyser (sentiment, intention, fraude)	⚠️ Transferts hors UE	Analyse locale en temps réel
Faire raisonner l'agent sur des données client	⚠️ Contexte sensible dans les prompts	Ollama local, données contextuelles locales
Conserver les enregistrements	⚠️ Rétention limitée du fournisseur, juridiction US	Rétention illimitée sur vos disques
Attester l'accessibilité aux régulateurs	⚠️ Dépend du tiers	Audit log illimité, traçabilité NSC
Détecter la fraude en temps réel	⚠️ Selon API exposée	Pipeline local, latence milliseconde

La colonne de droite n'est pas un confort : c'est souvent la différence entre déployable et bloqué en comité conformité.

Le cas d'usage intégré : centre d'appels bancaire

Concrètement, ce que DalonCorp propose on-premise :

En temps réel pendant l'appel

• Transcription streaming (Whisper), l'agent voit la conversation se former
• Détection de fraude vocale : analyse des motifs (urgence, pression, demande inhabituelle de transfert), alerte agent, flag IA
• Coaching temps réel des agents (script compliance, information obligatoire)

Automatiquement après l'appel

• Résumé structuré (qualité, conformité, prochaine action), via NLPBC/Ollama
• Score et catégorisation (plainte ? cross-sell ? fraude suspectée ?)
• Archivage réglementaire avec durée conforme à votre cadre

En protection le pipeline d'AAGuard bannit les IP qui cherchent à exploiter l'infrastructure d'enregistrement.

L'argument DORA : la souveraineté comme exigence réglementaire

DORA ne dit pas « tout on-prem », elle impose la maîtrise des risques fournisseurs. Or, en 2026, un fournisseur SaaS de Voice AI sous juridiction US est par définition un risque de concentration et de sous-traitance en cascade (chaîne de tiers non maîtrisable).

L'architecture on-premise est la réponse la plus simple à un article DORA : pas de fournisseur critique supplémentaire pour l'analyse vocale, l'infrastructure est la vôtre, testée, monitorée, documentée. Les obligations de tests de résilience (tests de scénarios de crise) se font sur votre infrastructure, pilotées par vos équipes.

Ce que ça change pour une banque

• Conformité par construction : RGPD, PCI-DSS, DORA, secret professionnel bancaire, aucune donnée ne quitte vos serveurs, rétention illimitée possible
• Détection de fraude vocale en production : analyse sémantique en temps réel (urgences suspectes, demandes inhabituelles), signal de risque agent
• Clonage vocal neutralisé : l'authentification n'est plus basée sur la voix seule, NSC cryptographique côté client, plus résilient au clonage
• 0€ de coût AI récurrent : le calcul on-prem standard, des millions de minutes analysées au même coût électrique

Pour aller plus loin

• La sécurité de bout en bout, les 5 couches, dont le Guardian IA (PCI-DSS)
• La chaîne vocale temps réel, Whisper et Piper pour les call centers
• L'article sur le Patriot Act, pourquoi le cloud US est intenable en finance
• Télécharger la proposition de valeur (PDF)

Troisième volet de notre série verticale. Ici : le secteur où la Voice AI a le plus à apporter, et où elle est juridiquement la plus encadrée.

La scène qui se joue des milliers de fois par jour

Un médecin termine sa consultation. Pendant les douze minutes qui viennent de s'écouler, il a écouté, examiné, décidé, et il lui reste maintenant quinze minutes de frappe pour retranscrire tout cela dans le dossier patient. Multipliez par le nombre de consultations, ajoutez le burn-out documentaire que dénoncent les ordres professionnels depuis des années : la transcription automatique par IA est l'un des gains de temps les plus évidents de la médecine moderne.

Alors l'établissement teste un outil de transcription. Voix claire, ponctuation automatique, intégration au DPI (Dossier Patient Informatisé). Le pilote est convaincant.

Et puis la question arrive : où vont les données ?

Ce que dit le droit, et il ne rigole pas

Les données de santé sont la catégorie la plus protégée du RGPD (article 9 : données sensibles). À cela s'ajoutent des régimes spécifiques :

L'hébergement HDS (Health Data Hosting)

En France, tout hébergeur de données de santé à caractère personnel doit être certifié HDS, un régime dédié, avec des exigences au-delà de l'ISO 27001 classique. Interrogez donc votre fournisseur SaaS de transcription : êtes-vous certifié HDS ? Sur quel périmètre ? La réponse est fréquemment un silence, ou un « nous travaillons dessus ».

La voix est une donnée biométrique

Une voix n'est pas un texte : c'est un élément biométrique qui identifie (et peut identifier) une personne. Transcrire la voix d'un patient revient à traiter une donnée de santé et une donnée biométrique, double qualification, double exigence.

Le secret médical

Une consultation contient ce que le patient n'a dit qu'à son médecin. Le secret médical s'étend à tous les intervenants de la chaîne, y compris les sous-traitants techniques du fournisseur de transcription. Or une chaîne SaaS typique implique : l'éditeur (US ?), son hébergeur (US ? AWS/Azure ?), ses sous-traitants d'inférence, l'ensemble hors du contrôle du praticien.

Et le CLOUD Act de creuser le problème : un éditeur américain certifié HDS sur papier reste sous juridiction US. L'analyse détaillée est dans notre article dédié, Patriot Act, CLOUD Act, FISA : ces lois permettent la réquisition des données détenues par un fournisseur US quel que soit l'endroit où elles sont hébergées.

Le test des cinq questions

Avant tout outil de transcription en santé, le RSSI/DPO doit pouvoir répondre :

1. Où physiquement tourne l'inférence ? (Si SaaS : quels pays exactement, y a-t-il burst vers d'autres régions ?) 2. L'audio est-il conservé après transcription ? (Beaucoup le gardent par défaut pour « améliorer le service ») 3. Les transcriptions alimentent-elles un entraînement de modèle ? (Opt-out explicite ou opt-in silencieux ?) 4. L'hébergeur est-il certifié HDS, et pour quelle portée ? 5. En cas de réquisition étrangère, serai-je informé ? (Avec le Patriot Act/CLOUD Act : non.)

Si une seule réponse est inconfortable, l'outil est disqualifié pour un usage clinique.

Ce que la chaîne on-premise change

La réponse DalonCorp s'appelle l'infrastructure du praticien, et elle est complète :

Étape	Composant	Localisation
Capture	Micro/praticien → LiveKit SIP ou application	Votre réseau
Transcription	Whisper on-prem (30+ langues, diarization médecin/patient)	Vos GPU
Compréhension / résumé	LLM via NLPBC, Ollama on-prem (Llama 3.1, Mistral)	Vos GPU
Synthèse vocale (réponse, assistance)	Piper sub-200ms	Vos GPU
Stockage	Dossier patient, transcriptions	Vos serveurs (NATS Object Store)
Identité	NSC Ed25519, chaque accès tracé par personne	Vos contrôleurs
Journalisation	Audit log complet, rétention illimitée possible	Vos disques

Aucune donnée de santé ne quitte l'établissement. Pas de DPA à négocier avec un cloud US, pas de DPF à réévaluer après chaque décision CJUE, pas de question « où est physiquement le serveur ».

Les usages concrets en établissement

• Consultation → compte-rendu : le médecin dicte ou l'IA transcrit la consultation ; le NLPBC résume et structure en sections (anamnèse, examen, diagnostic, prescription) prêtes à intégrer au dossier
• Assistance en consultation : l'assistant vocal interroge le dossier (« ses derniers bilans ? ») pendant que le praticien examine, mains libres
• Télémédecine : transcription des téléconsultations, avec double consentement vocal
• Accessibilité patients : sous-titrage en direct pour patients malentendants, synthèse vocale pour malvoyants, l'accessibilité RGAA n'est pas une option en établissement public
• Urgences : mains libres absolues, la voix est le seul canal disponible pendant les gestes techniques.

Une objection fréquente : « Whisper, c'est du machine learning, donc un traitement automatisé ? »

Oui, et c'est précisément pourquoi l'AI Act est votre allié ici : il exige la supervision humaine (le médecin valide la transcription), la journalisation (audit log DalonCorp) et la transparence (le patient est informé). Trois points où l'architecture DalonCorp est déjà conforme par construction, le médecin valide, le système trace, rien n'est décisionnel.

Pour aller plus loin

• La chaîne vocale temps réel, Whisper et Piper en détail
• La sécurité de bout en bout, les 5 couches, dont la conformité santé
• La proposition de valeur DalonCorp (PDF)

Le calcul que personne ne fait avant de signer : ce que coûte réellement un LLM en production, hors marketing. Hypothèses explicitées, chiffres vérifiables.

Le piège du « pay-as-you-go »

L'argument commercial d'OpenAI, Google et consorts est séduisant : pas d'investissement initial, vous ne payez que ce que vous consommez. Pour un prototype, c'est vrai, et c'est voulu. Le modèle freemium est conçu pour que l'on entre gratuitement et que l'on ne ressorte jamais.

Le problème apparaît à l'échelle. Détaillons.

Les hypothèses (à adapter à votre cas)

Prenons le cas d'étude type : un centre d'appels européen de taille moyenne :

• 10 000 appels / jour traités par IA (assistance, qualification, résumés)
• 2 minutes d'appel en moyenne
• ~800 tokens LLM par appel (contexte + réponse)
• × 220 jours ouvrés / an

Cela représente ~1,76 milliard de tokens par an en entrée + sortie cumulées.

Le coût cloud, année après année

À ~12,50 €/million de tokens (tarif GPT-4o mixte entrée/sortie, tarif public 2026) :

Année	Tokens	Facture annuelle
1	1,76 Md	~ 22 000 €
3 (cumulé)	5,28 Md	~ 66 000 €

Où est le problème, me direz-vous ? C'est raisonnable. Sauf que :

1. Ce tarif ne tient pas compte des hausses, les prix API ont augmenté de 30-50 % en moyenne sur les 2 dernières années pour les modèles frontier.

2. Il ne couvre que le LLM. Ajoutez la transcription (Deepgram : ~0,0043 €/min → ~110 000 €/an pour 44 M min), la synthèse vocale, l'analyse de sentiment.

3. Il ne couvre que ce que vous mesurez. Les agents modernes re-promptent, réessayent, enrichissent le contexte : le facteur multiplicateur réel en production est fréquemment ×2 à ×3.

4. Le volume croît avec le succès : 10 000 appels aujourd'hui, 30 000 l'an prochain (votre service client décolle). La facture suit la croissance, et elle ne redescend jamais.

Avec ces corrections réalistes, le calcul cloud d'un centre d'appels moderne (STT + LLM + TTS) se situe entre 150 000 € et 300 000 € par an, et croît avec l'usage.

Le coût on-premise : le CAPEX qui tue l'OPEX

Poste	Coût	Commentaire
2× GPU A100 80 GB (ou équivalent)	60–80 K€	Le cœur du calcul, amorti sur 4-5 ans
Serveur complet (RAM, stockage, alim, cooling)	15–30 K€	Compris dans les fourchettes publiées
Électricité + maintenance	~2–4 K€/an	Le GPU traite 1 ou 1 M de tokens au même coût électrique
Licences modèles (Ollama, Llama, Mistral)	0 €	Open weights, usage commercial
DalonCorp (plateforme, support, mises à jour)	74 K€/an (1er datacenter, grille GYOI)	Le seul OPEX réel : 23 services, support N3, mises à jour, NSC signing key annuelle

CAPEX initial : 46–100 K€ de matériel + la licence plateforme. Le GPU traite 1 token ou 1 million au même coût électrique.

Le point de rupture (break-even) se situe typiquement à moins de 12 mois pour un centre d'appels de cette taille. Au-delà, chaque année est de l'économie pure.

Ce qu'on ne vous dit pas sur le cloud

Trois arguments avancés pour justifier le cloud, examinés froidement :

« Le ROI est difficile, on garde le flexibilité. » Le cloud offre une flexibilité de démarrage, pas d'exploitation. Passer d'un provider à l'autre exige de réécrire les intégrations (API, SDK, facturation, auth), sauf si votre plateforme abstrait les providers, comme le NLPBC de DalonCorp (8 providers, routage par tenant).

« Ollama, c'est moins bon. » C'était vrai en 2023. Les modèles open weights 2025-2026 (Llama 3.1 70B, Mistral Large, DeepSeek) atteignent un niveau qui couvre la large majorité des usages métier, assistanat, qualification, résumé. Pour ceux qui nécessitent l'exception, votre plateforme peut offloader ce cas précis vers le cloud... et garder le sensible en local.

« On n'a pas les compétences GPU. » C'est le rôle d'un partenaire : l'infrastructure on-prem de DalonCorp se déploie avec la même discipline qu'une installation télécom, provisionnement automatisé via DevSecOps, monitoring Prometheus/Grafana, support N1-N3. La compétence GPU est notre métier.

Le calcul à 3 ans, côte à côte

Chiffres complets, licence plateforme incluse (grille GYOI : 124 K€ one-time + 74 K€/an, 1er datacenter) :

Scénario	Année 1	Année 2	Année 3	Total 3 ans
100 % cloud (STT+LLM+TTS facturés)	~180 K€	~190 K€	~200 K€	~570 K€
DalonCorp on-prem (CAPEX GPU + licence GYOI)	~313 K€	~74 K€	~74 K€	~461 K€

~109 K€ d'économie sur 3 ans, et c'est le plus petit de nos arguments. Car la comparaison ligne à ligne ne capture pas ce que le cloud ne vend pas :

• La souveraineté : aucune donnée ne quitte votre infrastructure, un argument sans équivalent tarifaire en secteur régulé
• La conformité : RGPD, AI Act, NIS2 par construction, pas par audit de fin de projet
• La gouvernance de la dépense : chaque token mesuré à la source et attribué à son utilisateur, le billing temps réel inclus dans la licence, pas une console fournisseur à consolider après coup
• La prévisibilité : la facture cloud suit le volume et les hausses de prix (30-50 % constatés sur 2 ans pour les modèles frontière), la licence est fixe

Et l'écart se creuse chaque année suivante : le cloud continue de facturer chaque token pendant que la licence reste plate et l'infrastructure s'amortit. Au 5e année, l'écart redevient massif.

Quand le cloud reste le bon choix

Honnêteté oblige (et notre architecture le permet) :

• Prototypage / POC : tester un cas d'usage sans CAPEX, le cloud est parfait. Notre plateforme est conçue pour le cloud offloading : vous démarrez cloud, vous basculez les charges sensibles en on-prem quand le volume ou la réglementation l'exige, sans réécrire le code.
• Volumes très faibles (< 500 appels/jour) : le calcul d'amortissement met des années, le pay-as-you-go reste rationnel.
• Crêtes exceptionnelles : un événement, un pic saisonnier, le cloud absorbe, l'infrastructure locale couvre le socle.

La question n'est pas « cloud ou on-prem » : c'est « quel service, sur quelle charge, avec quelle donnée ». Notre architecture NATS permet le mix au service près.

Le calcul pour votre organisation

Les chiffres ci-dessus utilisent des tarifs publics et des volumes types. Le calcul précis pour votre organisation dépend de : vos volumes actuels et projetés, vos exigences de latence, votre mix STT/LLM/TTS, votre profil de conformité.

Nous le faisons gratuitement dans le cadre d'un audit initial : apportez vos volumétries, nous sortons le calcul, avec les sources.

• Télécharger la proposition de valeur (PDF, tableaux complets)
• Notre positionnement souverain
• La sécurité de bout en bout

Le récit d'ingénierie derrière AAGuard, notre service open source de protection. Pour les ingénieurs qui veulent comprendre la mécanique, pas seulement le marketing.

Le problème : la fenêtre de tir de l'attaquant

Un scanner naïf sonde votre infrastructure méthodiquement : .env, .git/config, wp-admin, les CVE connues, les webmails, les panneaux admin. Chaque requête prend quelques dizaines de millisecondes, et chaque requête est un signal que quelque chose ne tourne pas normalement.

Les outils classiques réagissent en deux temps, deux vitesses :

• L'analyste SOC : détecte le pattern au tableau de bord… entre 10 et 60 minutes plus tard. L'attaquant a déjà cartographié vos endpoints, testé vos CVE, trouvé la porte.
• L'IPS de firewall classique : réagit, mais sur des signatures lourdes, avec des règles centrées paquet, les scans à basse cadence (1 req/s sur 100 chemins distincts) passent entre les mailles.

La fenêtre de tir de l'attaquant, c'est le délai entre sa première requête et votre réponse. AAGuard a été conçu pour que cette fenêtre mesure ~6 millisecondes.

L'architecture : trois composants, deux hôtes

[hôte applications]                [hôte firewall]
Apache / API / web                 /proc/net/nf_conntrack
sshd, logs NATS                    (poll 2s)
     │ tail inotify                     │ collector
     ▼                                  ▼
Correlator HTTP    ──── 6ms ────→ Correlator firewall
(signaux pondérés)                  (port scan, SYN flood,
     │                               conn flood, DDoS)
     └────────→ NATS ←───────────────┘
                    │
                    ▼
          Consumer nftables
          ban kernel-native, TTL 7j
                    │
     ┌──────────────┼──────────────┐
     ▼              ▼              ▼
AbuseIPDB      RDAP/SMTP      SQLite journal
(signal         (abuse desk      (tout conservé)
  mondial)        du FAI)

Deux hôtes, une seule connectique : NATS. L'hôte applicatif publie ses détections, l'hôte firewall les consomme et bannit au niveau kernel. Le même bus qui fait tourner le reste de la plateforme DalonCorp, une identification NSC, zéro connectique supplémentaire.

La mécanique : des signaux pondérés, pas des règles binaires

La faiblesse des IDS classiques : chaque règle déclenche ou ne déclenche pas. Résultat : les vrais scanners (lents, méthodiques) passent, les faux positifs (un script interne un peu bruyant) sont bannis.

AAGuard fonctionne autrement, par pondération accumulateur :

Signal	Poids
Path de sonde connu (critical)	1.0 → ban immédiat
Template Nuclei CVE (high)	0.9
User-agent scanner (high)	0.9
Rate excessif + 404s	0.7-0.9
Énumération webmail (medium)	0.7

Le corrélateur additionne les poids par IP :

• seuil ≥ 0.5 → détection (un seul signal high suffit)
• poids 1.0 → ban immédiat, première requête
• cooldown 30 s par IP : pas de double comptage
• allowlist IPv4/IPv6 : vos IP de monitoring et partenaires ne sont jamais suspects, quel que soit le trafic

C'est la différence entre un IDS qui crie et un système qui décide. Un scanner naïf (path de sonde seul : 0.9) est banni à la première requête. Un trafic ambigu accumule des preuves avant d'atteindre le seuil, les faux positifs n'ont pas d'espace de survie.

L'arme secrète : Nuclei en ingestion continue

AAGuard ne réinvente pas la détection CVE : il ingère les ~500 templates Nuclei (projectdiscovery) et en extrait automatiquement les chemins d'exploitation, des milliers de patterns actifs.

L'intelligence ajoutée :

• Corrélation par produit : vous associez chaque domaine au produit qui tourne dessus (gitea.osef.cloud: "gitea", dalon.*: "meteor"). Les templates d'autres produits sont ignorés, plus de faux positifs Drupal sur Gitea, ni PaperCut sur Meteor.
• Hot reload quotidien : systemd timer (3h), SIGHUP, les nouveaux CVE du jour sont actifs sans redémarrage.
• Filtrage par sévérité : critical/high/medium, seulement les templates vérifiés.
• Exclusions ciblées : les faux positifs identifiés sont blacklistés par ID de CVE (ex. cve_2026_9082).

Le ban kernel-native : pourquoi nftables

Le ban classique (iptables via process) a trois faiblesses : visible par l'application (overhead), perdu au reboot (sauf script de restauration), et séquentiel (le kernel traite les règles l'une après l'autre).

L'approche nftables d'AAGuard :

• Sets kernel-native (aaguard_banned_v4 / aaguard_banned_v6) : le lookup est O(1) kernel-side, insensible au nombre d'IPs bannies (1 351 aujourd'hui, la limite est celle de la mémoire set)
• Timeouts kernel : le TTL auto-expire dans le kernel, pas de timer applicatif à maintenir, pas de zombie ban si AAGuard s'arrête
• Persistence : les sets sont sauvegardés, un reboot n'efface pas la liste des attaquants
• Replay JetStream : en cas de redéploiement du firewall host, le Stream NATS rejoue les détections des dernières 24h, aucune IP ne revient par la porte

Le code est open source

Tout le code (détecteur, parser, corrélateur, consumer, CLI) est disponible :

gitea.osef.cloud/Dalon/aaguard

• Tests unitaires + RPC (NATS Embedded + JetStream)
• Benchmarks firewall + detector
• Docker compose pour déployer en 5 minutes

---

Cet article décrit la mécanique interne d'AAGuard. Pour le produit en tant que service : la page produit, ou la sécurité DalonCorp en 5 couches.

Pour aller plus loin

• Le produit AAGuard, la fiche vitrine
• La sécurité de bout en bout, les 5 couches defense-in-depth
• La proposition de valeur DalonCorp (PDF)