Prendre RDVContact
Retour à toutes les notes
7 juin 2026

Comment nous avons construit un relais d'IA hors ligne vers cloud en utilisant le Bluetooth et GPT-4o

Comment nous avons construit un relais d'IA hors ligne vers cloud en utilisant le Bluetooth et GPT-4o

Comment nous avons construit un relais d'IA hors ligne vers cloud en utilisant le Bluetooth et GPT-4o

Dans les environnements d'entreprise hautement sécurisés - tels que les salles de marchés financiers, les laboratoires de R&D sensibles et les structures liées à la défense - les stations de travail ont fréquemment interdiction d'accéder à l'internet public. Bien que cette isolation réseau (« air-gapping ») limite drastiquement les risques de fuite de données, elle rend les grands modèles de langage (LLM) hébergés dans le cloud totalement inaccessibles. Les ingénieurs et analystes se retrouvent ainsi coupés d'outils comme GPT-4o d'OpenAI, ce qui nuit à leur productivité.

Chez Seven Labs, nous avons été chargés de résoudre précisément ce problème pour un client opérant dans une zone réseau très restreinte. L'exigence était claire : permettre à des stations de travail situées sur un segment sans connexion internet de requêter de manière sécurisée des LLM dans le cloud, sans modifier les règles de pare-feu des machines et sans introduire de matériel non autorisé comme des clés Wi-Fi.

Notre solution a été le Bluetooth AI Relay - une passerelle edge-to-cloud qui achemine les requêtes locales d'un PC vers GPT-4o via un relais RFCOMM basé sur Android, en s'appuyant sur les protocoles Bluetooth standards. Voici l'analyse technique de la façon dont nous avons conçu, implémenté et sécurisé ce système en production.

1. Architecture du système : La passerelle Edge-to-Cloud

L'architecture repose sur trois composants clés :

  1. Le client (PC hors ligne) : Un service local s'exécutant sur la station de travail qui expose une API loopback (ex. http://localhost:8080/v1/chat/completions) conforme aux spécifications officielles de l'API OpenAI.
  2. Le relais (appareil mobile Android) : Une application React Native exécutant un service de premier plan Kotlin (Kotlin Foreground Service) dédié. L'appareil Android dispose d'un accès aux données cellulaires (LTE/5G) et au Bluetooth, faisant ainsi office de passerelle.
  3. Le cloud (OpenAI GPT-4o) : Le service de LLM cible joint via HTTPS.
+-------------+                     +-------------------------+                    +-----------------+
|   PC Hors   |      Bluetooth      |  Appareil Relais Android|    Réseau Mobile   |                 |
|    Ligne    |   (Socket RFCOMM)   |                         |   (Client HTTPS)   |  OpenAI GPT-4o  |
|  [Client]   |<===================>| [Service Kotlin]        |------------------->|   Point d'API   |
|             |                     | [Moteur React Native]   |                    |                 |
+-------------+                     +-------------------------+                    +-----------------+

Pourquoi RFCOMM ?

Pour transmettre les charges utiles (payloads) JSON brutes des requêtes et réponses de prompts, nous avions besoin d'un protocole de transport orienté flux et fiable. Bien que le Bluetooth Low Energy (BLE) avec ses attributs GATT soit excellent pour la télémétrie à faible débit, il est inadapté au transfert de blocs de texte volumineux en raison de ses limites strictes d'MTU (Maximum Transmission Unit) et de la surcharge liée à la fragmentation des paquets.

Nous avons choisi RFCOMM (Radio Frequency Communication), qui émule un port série RS-232 sur le protocole L2CAP. RFCOMM gère nativement le séquençage des paquets, le contrôle de flux et les retransmissions, fournissant un socket fiable orienté flux (similaire à l'interface java.net.Socket) capable de soutenir le débit requis pour le streaming des prompts et réponses des LLM.

2. Implémentation du serveur RFCOMM Android en Kotlin

Pour garantir que l'application Android puisse gérer les connexions Bluetooth de manière fiable, nous avons contourné les bibliothèques d'encapsulation React Native standards - qui souffrent souvent de fuites de mémoire et manquent de support pour la persistance en arrière-plan - et avons implémenté la pile Bluetooth directement en Kotlin.

Le Thread Serveur Bluetooth

Le serveur Bluetooth s'exécute sur un thread dédié, à l'écoute d'un identifiant unique universel (UUID) spécifique :

package com.sevenlabs.airelay

import android.bluetooth.BluetoothAdapter
import android.bluetooth.BluetoothServerSocket
import android.bluetooth.BluetoothSocket
import android.util.Log
import java.io.IOException
import java.util.UUID

class BluetoothServerThread(
    private val adapter: BluetoothAdapter,
    private val onConnectionEstablished: (BluetoothSocket) -> Unit
) : Thread() {

    private val serverSocket: BluetoothServerSocket? by lazy(LazyThreadSafetyMode.SYNCHRONIZED) {
        adapter.listenUsingRfcommWithServiceRecord(
            "SevenLabsAIRelay",
            UUID.fromString("4a8b8c2d-9e0f-11ed-a8fc-0242ac120002")
        )
    }

    private var shouldKeepListening = true

    override fun run() {
        name = "SevenLabs-RFCOMM-Listener"
        Log.i("AIRelay", "RFCOMM Server Socket listening...")

        while (shouldKeepListening) {
            val socket: BluetoothSocket = try {
                serverSocket?.accept()
            } catch (e: IOException) {
                Log.e("AIRelay", "Server Socket accept failed", e)
                break
            }

            socket?.let {
                Log.i("AIRelay", "Incoming RFCOMM client connection accepted")
                onConnectionEstablished(it)
            }
        }
    }

    fun cancel() {
        try {
            shouldKeepListening = false
            serverSocket?.close()
        } catch (e: IOException) {
            Log.e("AIRelay", "Could not close server socket", e)
        }
    }
}

3. Fonctionnement persistant : Services de premier plan Kotlin et Wake-Locks

L'un des défis d'ingénierie les plus complexes sur les versions récentes d'Android (Android 12+) réside dans les optimisations de la batterie. Si l'écran de l'appareil mobile s'éteint ou si l'application est réduite, le système d'exploitation place le processeur en sommeil profond (mode Doze) et interrompt les sockets réseau en arrière-plan.

Pour garantir un fonctionnement ininterrompu, Seven Labs a mis en œuvre deux mécanismes clés :

  1. Service de premier plan Kotlin (Foreground Service) : Intégration du serveur RFCOMM et du client d'API au sein d'un service de premier plan Android. Cela enregistre l'application comme un processus persistant reconnu par le système, affichant une notification permanente dans la barre d'état.
  2. Wake-Locks et Wi-Fi Locks : Instructions explicites données au planificateur du noyau pour maintenir le processeur éveillé et les puces réseau actives lors d'une session active.

Implémentation du service de premier plan

Voici le cœur du service de premier plan qui gère le cycle de vie du thread et les notifications :

package com.sevenlabs.airelay

import android.app.Notification
import android.app.NotificationChannel
import android.app.NotificationManager
import android.app.PendingIntent
import android.app.Service
import android.content.Context
import android.content.Intent
import android.os.Build
import android.os.IBinder
import android.os.PowerManager
import androidx.core.app.NotificationCompat

class AIRelayService : Service() {

    private var wakeLock: PowerManager.WakeLock? = null
    private var serverThread: BluetoothServerThread? = null

    override fun onCreate() {
        super.onCreate()
        acquireWakeLock()
        startForegroundService()
    }

    private fun acquireWakeLock() {
        val powerManager = getSystemService(Context.POWER_SERVICE) as PowerManager
        wakeLock = powerManager.newWakeLock(
            PowerManager.PARTIAL_WAKE_LOCK,
            "SevenLabs::AIRelayWakeLock"
        ).apply {
            acquire(30 * 60 * 1000L) // Limite de sécurité de 30 minutes
        }
    }

    private fun startForegroundService() {
        val channelId = "seven_labs_ai_relay"
        val channelName = "AI Relay Foreground Service"

        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
            val channel = NotificationChannel(channelId, channelName, NotificationManager.IMPORTANCE_LOW)
            val manager = getSystemService(Context.NOTIFICATION_SERVICE) as NotificationManager
            manager.createNotificationChannel(channel)
        }

        val notificationIntent = Intent(this, MainActivity::class.java)
        val pendingIntent = PendingIntent.getActivity(
            this, 0, notificationIntent,
            PendingIntent.FLAG_IMMUTABLE or PendingIntent.FLAG_UPDATE_CURRENT
        )

        val notification: Notification = NotificationCompat.Builder(this, channelId)
            .setContentTitle("Seven Labs AI Relay Actif")
            .setContentText("Acheminement des données Bluetooth RFCOMM vers GPT-4o...")
            .setSmallIcon(R.drawable.ic_notification)
            .setContentIntent(pendingIntent)
            .build()

        startForeground(1, notification)
    }

    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
        val adapter = BluetoothAdapter.getDefaultAdapter()
        serverThread = BluetoothServerThread(adapter) { socket ->
            ConnectionHandler(socket).start()
        }
        serverThread?.start()
        return START_STICKY
    }

    override fun onDestroy() {
        serverThread?.cancel()
        wakeLock?.let {
            if (it.isHeld) it.release()
        }
        super.onDestroy()
    }

    override fun onBind(intent: Intent?): IBinder? = null
}

4. Structure de la charge utile de données et protocole

RFCOMM fonctionnant comme un flux d'octets bruts, nous avons dû définir un protocole de découpage au niveau de la couche applicative pour segmenter les paquets de requêtes et de réponses.

Nous avons conçu un format de trame de message léger :

  • Magic Bytes (4 octets) : SLAR (Seven Labs AI Relay) pour valider l'origine des paquets.
  • Taille de la charge utile (4 octets) : Entier au format Big-Endian spécifiant la taille exacte de la charge utile.
  • Type de charge utile (1 octet) : Indique s'il s'agit de texte brut, d'un segment SSE (Server-Sent Events), de métadonnées ou d'un code d'erreur.
  • Charge utile chiffrée (Variable) : Données JSON chiffrées avec AES-GCM.
+------------+------------------+--------------+-----------------------+
| Magic (4B) | Taille (4B, Int) | Type (1B, B) | Charge Chiffrée (N)   |
+------------+------------------+--------------+-----------------------+

Lorsque le client sur le PC hors ligne envoie un prompt de complétion, le démon local l'encapsule dans cette trame, le transmet sur le socket RFCOMM et se bloque en attendant les trames de réponse.

Du côté du relais Android, le lecteur de socket Kotlin lit le préfixe de taille, extrait le nombre d'octets spécifié, déchiffre la charge utile et transmet la requête HTTP vers le point d'accès d'OpenAI. Pour prendre en charge le streaming des tokens, nous analysons les flux Server-Sent Events (SSE) retournés par OpenAI, les encapsulons sous forme de trames de type SSE Chunk et les écrivons séquentiellement dans le flux du socket Bluetooth.

5. Architecture de sécurité : Zero-Trust sur le Bluetooth

Transmettre des données d'entreprise via Bluetooth soulève des préoccupations de sécurité légitimes. Les connexions Bluetooth sont sensibles aux écoutes clandestines et aux attaques de l'homme du milieu (MitM). Pour rendre ce relais viable dans des déploiements d'entreprise, Seven Labs a ajouté une couche cryptographique au niveau applicatif.

Chiffrement de bout en bout (E2EE)

Même si la couche d'appairage Bluetooth est compromise, la charge utile des données reste chiffrée et sécurisée.

  1. Échange de clés : Lorsque le PC hors ligne initie la connexion, il effectue un échange de clés Elliptic-Curve Diffie-Hellman (ECDH) avec l'appareil Android directement sur le socket Bluetooth brut.
  2. Clé de session éphémère : Les deux extrémités génèrent une clé symétrique partagée (AES-256-GCM) unique à cette session de connexion spécifique.
  3. Chiffrement de la charge utile : Chaque trame de données est chiffrée avec la clé de session, avec un vecteur d'initialisation (IV) généré pour chaque trame. Cela protège le flux contre les attaques par relecture et l'écoute réseau.

6. Optimisation des performances et de la latence

Nos benchmarks en environnement de production ont donné les indicateurs de performance suivants :

MétriqueWi-Fi Direct (Contrôle)Relais RFCOMM (Sans Streaming)Relais RFCOMM (Avec Streaming SSE)
Temps au premier token (TTFT)~320ms~980ms~410ms
Débit (Tokens/seconde)654258
Taille max charge utileIllimitée5 MoTransmise en continu

Optimisation du débit

Le Bluetooth disposant d'une bande passante restreinte par rapport au Wi-Fi, la transmission des réponses token par token est indispensable. En relayant les blocs SSE au client au fur et à mesure de leur réception depuis les serveurs d'OpenAI, nous réduisons le temps d'obtention du premier token (TTFT) de plus de 50 %.

De plus, nous appliquons une compression Gzip aux invites d'entrée (prompts) dépassant 20 Ko, ce qui diminue le temps de transfert Bluetooth et évite d'engorger les tampons RFCOMM.

7. Questions fréquemment posées par les entreprises

Ce système viole-t-il les principes d'isolation réseau (air-gapping) ?

Le système fonctionne comme un proxy de protocole strict. La station de travail hors ligne ne dispose d'aucun chemin d'accès IP vers le réseau cellulaire, ce qui empêche tout accès internet généralisé, scan de port ou vulnérabilité de type tunnel inversé (reverse shell). Seules les trames SLAR applicatives bien formées sont autorisées à traverser l'interface.

Quel est l'impact sur la batterie de l'appareil relais ?

L'utilisation simultanée des puces Bluetooth et cellulaires consomme environ 8 % de batterie par heure de traitement continu. En exploitant les Wake-Locks d'Android de manière ciblée - en maintenant le processeur actif uniquement lors des sessions de socket actives et en repassant en veille en dehors des heures de travail - nous avons minimisé cet impact.

Comment est gérée la comptabilisation des tokens ?

Toutes les clés d'utilisation et d'autorisation sont stockées sur l'application de relais Android ou récupérées auprès d'un serveur de clés d'entreprise. Les connexions individuelles des utilisateurs peuvent être authentifiées localement sur l'appareil avant la négociation Diffie-Hellman.

Schéma SEO technique & Liens internes

Développez des systèmes Edge-to-Cloud sécurisés avec Seven Labs

Associer des technologies d'IA avancées à des contrôles de sécurité d'entreprise rigoureux exige l'intervention d'architectes système chevronnés. Que vous ayez besoin d'un déploiement de LLM isolé, de calcul haute performance à la périphérie (edge) ou de relais IoT sécurisés, Seven Labs possède l'expertise technique pour concevoir et déployer vos solutions conformes.

Contactez l'équipe d'ingénierie de Seven Labs pour étudier les besoins d'infrastructure et d'IA personnalisés de votre organisation.

Service Seven Labs

Développement d'Agents IA & Pipelines RAG

Nous construisons des pipelines RAG de production. Voir notre travail →
Loading...

Lire la suite

Advanced RAG Chunking Strategies: The Definite Guide

Implementing Advanced RAG Chunking Strategies separates production-grade LLM applications from fragi...

Lire l'article

Bluetooth as an AI Transport Layer: Lessons from Production

A production-focused guide to using Bluetooth RFCOMM as an AI transport channel. Learn about socket ...

Lire l'article
Chat with us