Juan E. Riojas, directeur des systèmes d’information chez Bland – Série d’entretiens

Juan E. Riojas, directeur des systèmes d’information chez Bland, est un dirigeant chevronné dans les domaines de la technologie et des données. Sa carrière couvre l’informatique d’entreprise, la gestion des données, l’analytique, les opérations et la transformation numérique. Avant de rejoindre Bland en décembre 2025, il a occupé le poste de directeur des systèmes d’information chez Twilio et Rackspace Technology, après avoir exercé des fonctions de direction chez Informatica, en tant que directeur des données, et chez Gogo, en tant que vice-président de la gestion et de l’analytique des données. Son parcours comprend également des postes de direction des opérations et de gestion chez Dell, Accenture, Expeditors International, OfficeMax et AxonGroup, qui lui ont permis d’acquérir une vaste expérience de la gestion d’initiatives technologiques et liées aux données au sein de grandes organisations.

Bland est une entreprise spécialisée dans l’IA vocale pour les entreprises. Elle développe des agents d’IA capables de gérer les appels entrants et sortants, le service client, la prise de rendez-vous, la collecte d’informations, le routage et d’autres flux de travail complexes. Sa plateforme met l’accent sur la maîtrise de l’ensemble des technologies sous-jacentes : Bland développe et exploite ses propres modèles vocaux, linguistiques et de parole, et propose des déploiements sur Bland Cloud, dans des clouds privés virtuels ou dans des environnements d’entreprise entièrement auto-hébergés et isolés des réseaux externes. L’entreprise se concentre particulièrement sur les cas d’usage soumis à une réglementation ou à des exigences de sécurité strictes, avec des fonctionnalités telles que des parcours conversationnels, des intégrations aux systèmes de téléphonie existants, une conservation configurable des données, des contrôles d’accès fondés sur les rôles et des fonctionnalités de conformité destinées aux entreprises.

Vous avez occupé des postes de directeur des systèmes d’information chez Twilio et Rackspace, été directeur des données chez Informatica et consacré une grande partie de votre carrière aux infrastructures de communication et aux données d’entreprise. Que vous ont appris ces expériences sur les obstacles auxquels les entreprises sont confrontées dans le domaine de l’IA, et comment ont-elles influencé la plateforme auto-hébergée que vous développez aujourd’hui chez Bland ?

Mon expérience chez Twilio, Rackspace et Informatica m’a appris que le principal obstacle à l’adoption de l’IA en entreprise n’est pas la technologie, mais la confiance, la maîtrise et la capacité à l’exploiter en toute sécurité à grande échelle. Les entreprises doivent savoir où se trouvent leurs données, qui les contrôle et si l’IA peut s’intégrer aux cadres de sécurité et de gouvernance qu’elles ont mis des années à élaborer. Cela a façonné notre approche chez Bland : offrir aux entreprises une plateforme auto-hébergée qui leur donne accès à la puissance de l’IA sans les obliger à renoncer à la maîtrise de leur infrastructure ou de leurs données.

Bland est la seule plateforme d’IA vocale auto-hébergée, ce qui signifie que vous possédez chaque couche de l’orchestration de l’IA : la conversion de la parole en texte, l’inférence des grands modèles de langage (LLM) et la synthèse vocale. Pourquoi Bland a-t-elle choisi cette approche, et quels ont été les défis techniques les plus difficiles à relever pour maîtriser l’ensemble de la chaîne technologique de l’IA vocale ?

Nous avons choisi d’héberger nous-mêmes et de maîtriser chaque couche, de la reconnaissance automatique de la parole (ASR) au raisonnement des grands modèles de langage (LLM), en passant par la synthèse vocale (TTS), pour trois raisons : une latence conversationnelle inférieure à une seconde, des limites strictes en matière de confidentialité des données et une grande fiabilité opérationnelle.

Lorsqu’on enchaîne des prestataires externes différents, les délais s’additionnent. Les allers-retours sur le réseau, les délais d’attente dans des files indépendantes et les démarrages à froid se cumulent. Il en résulte une pause artificielle qui rompt le fil de la conversation.

En hébergeant nos modèles au même endroit dans un environnement d’exécution unifié et en supprimant les dépendances aux API de tiers, nous éliminons ces allers-retours. Cela nous garantit également une souveraineté totale sur les données : les flux vocaux sensibles et les transcriptions ne sont jamais transmis à des fournisseurs externes de modèles de pointe.

Les principaux défis techniques concernaient l’orchestration de la latence, la synchronisation des flux et la planification des tâches sur les GPU soumis à une forte concurrence. La voix bidirectionnelle en temps réel exige une génération fluide des jetons en continu. Le moteur de synthèse vocale doit commencer à produire l’audio avant même que le grand modèle de langage ait fini de générer la phrase.

Pour y parvenir, nous avons conçu des moteurs d’inférence personnalisés, des pipelines de décodage spéculatif à faible latence et des adaptations de modèles acoustiques. Ensemble, ils préviennent les saccades, gèrent l’alternance des tours de parole et permettent de traiter avec fluidité les interruptions de l’utilisateur, le tout sans saturer la mémoire des GPU.

De nombreuses plateformes d’IA vocale combinent la transcription, le raisonnement et la génération vocale en faisant appel à différents prestataires tiers. Quels avantages et compromis techniques présente le fait que Bland maîtrise et exploite elle-même une plus grande partie de cette chaîne technologique ?

Le principal avantage est la maîtrise de la latence de bout en bout. Il n’y a aucune surcharge réseau entre la reconnaissance automatique de la parole, le grand modèle de langage et la synthèse vocale. Nous pouvons donc exécuter des pipelines de traitement en continu unifiés, optimiser les différentes couches ensemble et maîtriser précisément le délai avant le premier octet. Il est tout simplement impossible d’atteindre ce niveau de contrôle lorsque chaque composant provient d’un prestataire différent.

Le deuxième avantage est de disposer d’un périmètre unifié en matière de sécurité et de conformité. Les données ne quittent jamais notre environnement contrôlé : l’audio et les transcriptions des clients restent dans notre périmètre vérifié. Cela élimine les risques liés aux sous-traitants ultérieurs et simplifie considérablement la conformité aux normes HIPAA, SOC 2 et PCI DSS. Toute personne ayant déjà passé un audit de sécurité auprès d’un fournisseur sait à quel point cela compte.

Le troisième avantage est la prévisibilité des coûts. Nous ne payons pas de majoration par jeton ou par minute pour les API externes de modèles de fondation ; nos coûts unitaires restent donc prévisibles à l’échelle de l’entreprise. Et comme les modèles nous appartiennent, nous pouvons ajuster directement les paramètres acoustiques, la prosodie et les poids associés au raisonnement propre à chaque tâche.

Tout cela a toutefois un coût. Cette approche exige beaucoup d’infrastructures et de capitaux consacrés aux GPU. La gestion de vastes parcs de GPU dédiés nécessite une planification, une orchestration et un basculement interrégional sophistiqués, et les coûts matériels sont élevés.

Nous assumons également nous-mêmes la charge de la maintenance et de la spécialisation des modèles. Nous ne pouvons pas confier la recherche de pointe à des fournisseurs externes. Nous prenons plutôt en charge le travail d’ingénierie continu nécessaire pour entraîner, évaluer et maintenir des modèles développés en interne, adaptés à une grande diversité d’accents, de conditions de bruit ambiant et de langues.

Pour nous, ce compromis en vaut la peine.

Bland a obtenu la certification FedRAMP 20x Class A en août et affirme être la première plateforme d’IA vocale à la détenir. La plupart des lecteurs ne connaissent probablement pas la certification 20x par rapport à l’ancien FedRAMP. Qu’est-ce que la Class A, et qu’avez-vous réellement dû démontrer pour l’obtenir ?

FedRAMP 20x est un cadre modernisé, conçu pour le cloud, introduit dans le cadre des FedRAMP Consolidated Rules for 2026 (CR26). L’ancien processus classait tous les systèmes selon les niveaux d’impact FIPS 199 (faible, modéré et élevé) et était réputé pour la lourdeur de ses formalités administratives. Le programme 20x remplace ces niveaux par des classes de certification désignées par des lettres : A, B, C et D.

La Class A est le niveau d’entrée. Elle est conçue spécifiquement pour les fournisseurs commerciaux de services cloud (CSP) qui disposent déjà de programmes de sécurité éprouvés et souhaitent accéder au marché fédéral. Voyez-la comme une porte d’entrée, et non comme une destination définitive. Vous obtenez une certification de programme reconnue, délivrée directement par le FedRAMP Program Management Office (PMO), puis disposez de 2 ans pour passer à la Class B, C ou D.

Pour y parvenir, nous avons dû démontrer quatre choses. Premièrement, disposer d’un audit SOC 2 Type II récent et vérifié, couvrant les principes fondamentaux de sécurité, de confidentialité et de disponibilité. Deuxièmement, définir clairement et isoler logiquement un périmètre de services cloud fédéraux englobant nos services vocaux, SMS et de clavardage.

Troisièmement, mettre en œuvre les éléments de base des indicateurs clés de sécurité (KSI) obligatoires de FedRAMP 20x et être prêts à assurer une surveillance continue. Cela comprend l’analyse des vulnérabilités, les procédures de réponse aux incidents, l’application des contrôles d’accès et la production continue de rapports de sécurité lisibles par machine.

C’est sur le quatrième point que la maîtrise de notre pile technologique nous a vraiment avantagés. Nous avons dû vérifier que la transcription, le raisonnement et la synthèse vocale s’exécutent entièrement à l’intérieur du périmètre de conteneurs autorisé de Bland, sans transmettre de données fédérales à des fournisseurs tiers non vérifiés d’IA de pointe. Pour une plateforme assemblée à partir de composants de fournisseurs externes, il est très difficile de satisfaire à cette exigence.

Bland prend en charge des déploiements allant des VPC de cloud privé aux infrastructures GPU dédiées sur site. Comment l’architecture évolue-t-elle selon ces modèles de déploiement, notamment en ce qui concerne la latence, la mise à l’échelle et les exigences en matière d’infrastructure ?

En bref, plus on se rapproche d’un déploiement sur site, plus on gagne en latence et en contrôle, mais plus on renonce à l’élasticité.

Commençons par la latence. Les déploiements sur site et les VPC dédiés réduisent tous deux au minimum le transit par les réseaux externes, car ils se trouvent à proximité immédiate des lignes téléphoniques internes et des passerelles SIP de l’entreprise. Dans un VPC de cloud privé, sur AWS ou GCP par exemple, la latence dépend des réseaux intrarégionaux et des interconnexions cloud. Le matériel dédié sur site, installé sur des serveurs physiques sans virtualisation, va encore plus loin. Il élimine complètement les couches de virtualisation de l’hyperviseur et le routage par l’Internet public, ce qui permet d’obtenir la gigue acoustique la plus faible possible.

C’est au niveau de la mise à l’échelle que le compromis se fait sentir. Dans un VPC cloud, nous effectuons une mise à l’échelle horizontale grâce à une orchestration élastique, par exemple des grappes Kubernetes à mise à l’échelle automatique soutenues par des instances cloud équipées de GPU, de sorte que la capacité s’ajuste dynamiquement lorsque le volume d’appels augmente brusquement. Sur site, cela ne fonctionne pas de la même manière. La capacité est plafonnée par un nombre fixe de GPU physiques, ce qui impose un contrôle strict des admissions, des politiques de mise en file d’attente et un provisionnement matériel statique fondé sur le volume maximal d’appels simultanés. Il faut prévoir à l’avance la journée la plus chargée.

Les exigences en matière d’infrastructure sont également très différentes. Les déploiements dans un VPC privé peuvent s’appuyer sur le stockage cloud géré, l’IAM natif et la gestion des secrets par le fournisseur cloud. Les installations sur site nécessitent des grappes de GPU dédiées montées en rack (des accélérateurs professionnels NVIDIA, par exemple), des réseaux locaux à haut débit, des modules de sécurité matériels (HSM) ou des coffres-forts de clés locaux, ainsi que des collecteurs de télémétrie locaux. Et tous ces composants doivent s’exécuter sur des environnements d’exécution de conteneurs d’entreprise capables de fonctionner dans des environnements entièrement isolés ou à sortie réseau restreinte.

Bland permet aux entreprises de contrôler les mises en production, de maintenir des environnements de test distincts et de déployer de nouvelles versions en canari sur une partie des appels réels avant de les déployer plus largement. Pourquoi les pratiques traditionnelles de mise en production logicielle deviennent-elles particulièrement importantes à mesure que les agents d’IA sont utilisés en production dans des environnements en contact avec les clients ?

C’est parce que les agents d’IA ne se comportent pas comme les logiciels d’entreprise traditionnels.

Un logiciel déterministe fait la même chose à chaque fois. Les agents d’IA générative sont probabilistes et non déterministes. Une légère modification d’invite, une mise à jour des poids du modèle ou un changement de parcours peut involontairement entraîner une régression conversationnelle, une hallucination ou une violation d’une politique de conformité. Souvent, rien dans la modification elle-même ne permet de prévoir que cela va se produire.

C’est pourquoi la discipline de mise en production traditionnelle est aujourd’hui plus importante que jamais. Des environnements de préproduction isolés et des tests de régression rigoureux fondés sur des corpus historiques d’appels permettent de détecter de nombreux problèmes avant la mise en service. Les déploiements canaris vont encore plus loin. On déploie la nouvelle version sur un pourcentage contrôlé des appels en direct et on surveille en temps réel des indicateurs comme la baisse du sentiment, le taux d’atteinte des objectifs, les pics de latence et les déclencheurs d’escalade ou de transfert. Tout cela se déroule avant que l’ensemble de la clientèle soit exposé à la nouvelle version.

C’est l’importance des enjeux qui rend cette discipline non négociable. Dans le service client, la gestion des sinistres ou la gestion de comptes, une défaillance peut entraîner une exposition réglementaire ou nuire gravement à l’image de marque. Un contrôle rigoureux des déploiements canaris et des retours arrière immédiats permettent d’éviter qu’une mauvaise mise à jour ne fasse la une des journaux.

Les banques, les organismes de santé, les assureurs et les agences gouvernementales sont souvent soumis à des exigences bien plus strictes que les autres entreprises pour déployer l’IA générative. Dans vos échanges avec ces organisations, qu’est-ce qui freine réellement aujourd’hui le déploiement de solutions vocales d’IA : la sécurité, la souveraineté des données, la fiabilité, la complexité de l’intégration, les achats ou autre chose ?

La sécurité et la souveraineté des données, et de loin, suivies de près par la complexité de l’intégration et les architectures héritées. C’est ce qui ressort constamment de nos échanges dans les secteurs bancaire, de la santé, de l’assurance et du gouvernement.

Du point de vue de la sécurité, les organisations soumises à une réglementation stricte ne peuvent tout simplement pas tolérer une architecture dans laquelle des flux audio sensibles, des informations de santé protégées (PHI) ou des renseignements personnels non publics franchissent le périmètre d’API externes ou sont conservés par des fournisseurs tiers de modèles à des fins d’entraînement. Pour ces acheteurs, l’auditabilité, les garanties de non-conservation des données et les exigences strictes de conformité, comme HIPAA, FedRAMP et PCI DSS, ne sont pas de simples avantages. Ce sont des conditions préalables incontournables. Si vous ne pouvez pas les respecter, la discussion s’arrête généralement là.

L’intégration constitue le prochain obstacle. Beaucoup de ces entreprises utilisent encore des systèmes PBX sur site anciens, des SVI complexes et des systèmes centraux de référence fragmentés, comme Epic ou Cerner dans le secteur de la santé, ou des systèmes centraux sur mainframe dans le secteur bancaire. Assurer la connexion des parcours conversationnels à ces environnements au moyen d’un accès API bidirectionnel en lecture et en écriture, en temps réel et à faible latence, entraîne une importante charge d’intégration.

Viennent ensuite les enjeux de fiabilité et le risque d’hallucination. Les équipes juridiques, de gestion des risques et des achats s’inquiètent à juste titre qu’un agent vocal autonome fournisse des conseils financiers, médicaux ou réglementaires inexacts. Avant d’approuver un déploiement à grande échelle en production, elles exigent des garde-fous détaillés, des solutions de repli conversationnelles déterministes et des procédures claires de transfert à un interlocuteur humain.

Merci pour cet excellent entretien. Les lecteurs qui souhaitent en savoir plus peuvent consulter Bland.