1. Qui fait quoi

RECscript transcrit des réunions sur Android. En mode passerelle, il n'appelle aucun de nos serveurs et aucun fournisseur d'IA directement : il appelle la vôtre, avec une clé que vous émettez, vers le modèle que vous avez choisi. C'est vous qui décidez du fournisseur, de sa juridiction, des quotas et de la journalisation.

2. Ce qui est demandé

L'application a besoin d'un modèle capable de transcrire un fichier audio avec séparation des intervenants. À ce jour, deux identifiants sont validés côté LiteLLM :

• voxtral-mini-latest
• voxtral-mini-2602

Le fournisseur derrière cet alias vous appartient : Mistral, un hébergeur européen, ou votre propre déploiement. RECscript ne le connaît pas et n'a pas besoin de le connaître.

3. Le config.yaml

Sur une installation LiteLLM, les modèles se déclarent dans le fichier config.yaml — celui que vous passez au serveur via --config, ou monté dans le conteneur. Ajoutez ces entrées à la section model_list existante, sans toucher au reste :

model_list:
  # ── Transcription : c'est cet alias que l'utilisateur saisira ──
  - model_name: voxtral-mini-latest
    litellm_params:
      model: mistral/voxtral-mini-latest
      api_key: os.environ/MISTRAL_API_KEY

  # ── Texte : comptes rendus et questions-réponses ──
  - model_name: ministral-8b-latest
    litellm_params:
      model: mistral/ministral-8b-latest
      api_key: os.environ/MISTRAL_API_KEY

Puis redémarrez la passerelle pour que la déclaration prenne effet. MISTRAL_API_KEY est ici une variable d'environnement du serveur LiteLLM : la clé du fournisseur reste chez vous, et ne descend jamais sur les postes.

Le nom que vous mettez dans model_name est libre : transcription-interne conviendrait tout aussi bien. C'est cet alias-là, et pas le nom du modèle sous-jacent, que l'utilisateur devra saisir dans l'application.

4. La clé virtuelle

Émettez une clé virtuelle de la passerelle pour l'application — jamais la clé du fournisseur. C'est tout l'intérêt du montage : le poste client ignore qui est le fournisseur, et vous coupez l'accès en révoquant la clé, sans passer par nous.

curl -X POST 'https://ia.votre-entreprise.fr/key/generate' \
  -H 'Authorization: Bearer $LITELLM_MASTER_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "models": ["voxtral-mini-latest", "ministral-8b-latest"],
    "key_alias": "recscript",
    "max_budget": 50
  }'

Vos politiques habituelles s'appliquent telles quelles : quotas par utilisateur, budgets, journalisation, filtrage. Ce sont celles de votre passerelle, pas les nôtres — nous n'avons aucun moyen de les contourner puisque nous ne sommes pas sur le chemin.

5. Ce qu'on remet à l'utilisateur

Trois valeurs, et rien d'autre :

Voici l'écran que votre collaborateur a sous les yeux — Réglages → Clé, carte Entreprise LiteLLM. Les trois champs y sont dans l'ordre du tableau ci-dessus :

Une fois les trois valeurs saisies, il appuie sur Tester la connexion puis sur Enregistrer. Le test vérifie la chaîne complète — adresse joignable, clé acceptée, modèle déclaré, format de réponse exploitable — avant le premier enregistrement, plutôt qu'après une réunion entière.

6. Deux écarts de protocole

Mesurés contre LiteLLM le 22 septembre 2026. L'application les traite déjà : vous n'avez rien à faire. Ils sont documentés ici parce qu'ils expliquent deux comportements qui, autrement, ressembleraient à des anomalies.

7. Dépannage

Les messages ci-dessous sont ceux que le bouton Tester la connexion affiche à l'utilisateur. Le détail technique renvoyé par la passerelle est toujours affiché en dessous, tel quel : demandez-le, c'est lui qui porte le diagnostic.

8. Ce que nous ne voyons pas

En mode passerelle, aucun contenu de réunion ne transite par nos serveurs, et ils ne sont même pas contactés : l'application appelle votre adresse, pas la nôtre. Les enregistrements, transcriptions et comptes rendus restent dans le stockage privé de l'application sur l'appareil.

Le seul échange qui nous concerne encore, dans l'offre Entreprise, est l'activation d'un appareil sous votre licence : nos serveurs voient qu'un appareil s'enrôle, jamais ce qu'il enregistre. Le détail des chemins d'appel est sur la page technique.

1. Who does what

RECscript transcribes meetings on Android. In gateway mode it calls none of our servers and no AI provider directly: it calls yours, with a key you issue, against the model you chose. You decide the provider, its jurisdiction, the quotas and the logging.

2. What is required

The app needs a model that can transcribe an audio file with speaker separation. As of today, two identifiers are validated on LiteLLM:

• voxtral-mini-latest
• voxtral-mini-2602

The provider behind that alias is yours: Mistral, a European host, or your own deployment. RECscript does not know it, and does not need to.

3. The config.yaml

On a LiteLLM install, models are declared in the config.yaml file — the one you pass to the server via --config, or mount into the container. Add these entries to the existing model_list section, leaving the rest untouched:

model_list:
  # ── Transcription: this is the alias the user will enter ──
  - model_name: voxtral-mini-latest
    litellm_params:
      model: mistral/voxtral-mini-latest
      api_key: os.environ/MISTRAL_API_KEY

  # ── Text: summaries and Q&A ──
  - model_name: ministral-8b-latest
    litellm_params:
      model: mistral/ministral-8b-latest
      api_key: os.environ/MISTRAL_API_KEY

Then restart the gateway for the declaration to take effect. MISTRAL_API_KEY here is an environment variable of the LiteLLM server: the provider key stays with you, and never reaches the devices.

The name you put in model_name is arbitrary: internal-transcription would do just as well. It is that alias, not the underlying model name, that the user has to enter in the app.

4. The virtual key

Issue a gateway virtual key for the app — never the provider key. That is the whole point of the arrangement: the device does not know who the provider is, and you cut access by revoking the key, without going through us.

curl -X POST 'https://ai.your-company.com/key/generate' \
  -H 'Authorization: Bearer $LITELLM_MASTER_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "models": ["voxtral-mini-latest", "ministral-8b-latest"],
    "key_alias": "recscript",
    "max_budget": 50
  }'

Your usual policies apply as they are: per-user quotas, budgets, logging, filtering. They are your gateway's, not ours — and we have no way to bypass them, since we are not on the path.

5. What you hand over

Three values, and nothing else:

This is the screen your colleague is looking at — Settings → Key, the Entreprise LiteLLM card. The three fields appear in the same order as the table above:

Once the three values are in, they press Test connection and then Save. The test checks the whole chain — address reachable, key accepted, model declared, response format usable — before the first recording rather than after a whole meeting.

6. Two protocol differences

Measured against LiteLLM on 22 September 2026. The app already handles them: there is nothing for you to do. They are documented here because they explain two behaviours that would otherwise look like faults.

7. Troubleshooting

The messages below are what the Test connection button shows the user. The technical detail returned by the gateway is always displayed underneath, verbatim: ask for it, that is what carries the diagnosis.

8. What we do not see

In gateway mode, no meeting content passes through our servers, and they are not even contacted: the app calls your address, not ours. Recordings, transcripts and summaries stay in the app's private storage on the device.

The only exchange that still involves us, under the Enterprise plan, is activating a device against your licence: our servers see that a device is enrolling, never what it records. The call paths are set out in detail on the technical page.