Chat IA souverain (A3)
En bref
Cette offre fournit aux équipes un espace de chat IA privé, administré pour leur organisation et hébergé en France ou dans l'Union européenne. Les utilisateurs peuvent y poser leurs questions dans un cadre défini par le client, avec des comptes individuels et une consommation maîtrisée. Le suivi mensuel associé, appelé suivi C dans le catalogue, maintient les accès et le service, suit l'usage, propose les mises à jour de modèles et apporte le support nécessaire.
Stack de référence de l'offre A3 et de ses options (A3.1 à A3.4).
Périmètre de la baseline
La baseline fournit un chat IA d'équipe dans un environnement maîtrisé :
- comptes individuels et rôle administrateur client ;
- modèle proposé selon le contexte du client ;
- inférence hébergée en France ou dans l'Union européenne ;
- mesure de l'usage par client, avec quota et jauge ;
- règles de gouvernance de base et formation initiale ;
- maintien opérationnel et mise à jour du modèle proposé dans le cadre du suivi.
Les automatisations de processus et agents spécialisés relèvent de l'offre A2. La connexion à une base documentaire, le SSO, l'accès à plusieurs modèles et l'environnement dédié sont des options A3.
Ce que signifie « souverain »
Dans l'offre A3, « souverain » signifie que l'emplacement des traitements, les fournisseurs et le cycle de vie des données sont connus et documentés. La baseline respecte les règles suivantes :
- Les données sont traitées en France ou dans l'Union européenne.
- Le fournisseur d'inférence est qualifié selon le principe d'agnosticisme et inscrit au registre des sous-traitants.
- Les entrées et sorties ne sont pas utilisées pour entraîner les modèles du fournisseur ; leur durée de conservation est connue contractuellement.
- Une clé ou un identifiant d'usage propre au client permet la mesure, le contrôle et la révocation des accès.
- Le modèle et le fournisseur peuvent être remplacés sans changer l'interface utilisée par les équipes.
- Les conversations et documents peuvent être exportés ou supprimés selon une procédure documentée.
La souveraineté ne signifie pas nécessairement qu'un GPU est réservé au client. L'isolation physique des ressources relève de l'environnement dédié (A3.4).
Architecture de référence
| Brique | Rôle | Règle |
|---|---|---|
| Application de chat | Comptes, conversations, administration et interface utilisateur | Instance ou espace isolé logiquement par client |
| Passerelle d'inférence | Routage vers les modèles, clés, quotas et mesure de l'usage | Point de passage unique pour tous les appels aux modèles |
| Fournisseur d'inférence | Exécution du modèle | Hébergement France ou UE, fournisseur qualifié |
| Stockage applicatif | Comptes, configuration et historique autorisé | Données séparées par client, sauvegardées et exportables |
| Supervision | Disponibilité, erreurs et consommation | Aucun contenu de conversation dans les logs techniques par défaut |
La brique applicative peut être développée en interne ou fondée sur un produit open source. Des solutions comme LibreChat, Open WebUI ou AnythingLLM couvrent déjà une partie importante du besoin. Avant de construire une application complète, elles doivent être évaluées sur la licence, la personnalisation, l'authentification, l'export des données et la transmission d'un identifiant utilisateur fiable à la passerelle d'inférence.
Quelle que soit l'option retenue, elle doit au minimum permettre : comptes individuels, administration client, désactivation d'un compte, export et suppression des conversations, configuration d'une durée de conservation, intégration SSO et affichage de la jauge d'usage.
Inférence et modèles proposés
La passerelle d'inférence découple l'application des fournisseurs et des modèles. Un changement de modèle ne doit pas nécessiter de migration de l'application ni de modification côté utilisateur.
Le modèle proposé dépend du contexte :
- métiers réglementés ou données sensibles : modèle d'un éditeur européen privilégié, sous réserve de qualification du fournisseur qui l'héberge ;
- autres contextes : arbitrage entre qualité, latence, coût et capacités, sans dépendance à un éditeur unique ;
- besoin spécifique : modèle différent après validation des contraintes de données, de licence et de qualité.
Le modèle proposé est réévalué dans le cadre du suivi. Toute bascule suit la procédure de mise à jour mensuelle du modèle : tests de non-régression, possibilité de rollback et information du client.
Comptes et gouvernance
- Chaque utilisateur dispose d'un compte nominatif ; les comptes partagés sont interdits.
- Le client désigne au moins un administrateur habilité à créer, désactiver et revoir les comptes.
- Les accès sont révoqués au départ d'un utilisateur ou à la demande de l'administrateur.
- La formation initiale couvre les usages autorisés, les données interdites, les limites des réponses et les règles de vérification humaine.
- La durée de conservation des conversations est définie avec le client et appliquée à l'environnement.
Quota et jauge
Chaque client dispose d'une mesure d'usage séparée. L'utilisateur voit une jauge en pourcentage plutôt que les volumes techniques ou les coûts d'inférence.
Les seuils, alertes, dépassements et révisions sont définis dans la procédure Quota et jauge d'usage. L'usage d'A3 ne doit pas pouvoir consommer le quota d'un autre client.
Base de connaissance (A3.2)
L'option A3.2 ajoute la recherche dans les documents du client :
- dépôt ou synchronisation des documents autorisés ;
- extraction et découpage du contenu ;
- calcul des embeddings ;
- indexation dans une collection isolée par client ;
- recherche sémantique et injection des extraits utiles dans la conversation ;
- affichage des sources utilisées dans la réponse.
La stack suit les mêmes règles que l'option A2.4 : modèle de génération interchangeable, modèle d'embedding stable et réindexation complète lors d'un changement d'embedding. PostgreSQL avec pgvector est utilisé par défaut. Qdrant est retenu uniquement lorsque la volumétrie, le filtrage, l'isolation ou les performances le justifient. Mistral Embed est le modèle d'embedding par défaut et multilingual-e5-large son alternative auto-hébergée.
La suppression d'un document doit entraîner sa suppression de l'index et des fichiers de travail. Les formats acceptés, la fréquence de synchronisation et les limites de volume sont définis pour chaque déploiement.
SSO (A3.1)
L'option A3.1 connecte l'application à l'IdP du client :
- authentification par protocole standard pris en charge par l'IdP et l'application ;
- attribution des rôles et révocation depuis l'annuaire ;
- compte administrateur de secours, protégé et documenté ;
- test de connexion, de déconnexion et de révocation avant livraison.
L'intégration est incluse lorsque le SSO du client a été déployé par Alpene dans le cadre de B3.1. Dans les autres cas, la compatibilité de l'IdP existant est vérifiée avant engagement.
Accès multi-modèles (A3.3)
L'option A3.3 permet au client d'utiliser plusieurs modèles depuis la même application. La liste est administrée par Alpene avec le client ; elle ne constitue pas un accès libre à tous les modèles du fournisseur.
Pour chaque modèle proposé sont documentés : fournisseur d'inférence, région de traitement, capacités principales, limites connues et cas d'usage recommandés. Tous les modèles passent par la même passerelle, la même mesure d'usage et les mêmes règles de conservation.
Environnement dédié (A3.4)
L'option A3.4 fournit des ressources d'inférence isolées pour le client :
- GPU ou capacité d'inférence réservée ;
- isolation réseau et secrets dédiés ;
- dimensionnement selon les modèles, la volumétrie et la latence attendue ;
- supervision, mises à jour et procédure de rollback propres à l'environnement ;
- arrêt et restitution documentés en fin de service.
Le dimensionnement est validé par un test de charge représentatif avant mise en production. Un environnement dédié n'exonère pas des exigences de réversibilité, de sauvegarde et de localisation des données.
Livraison
Chaque déploiement A3 est livré avec :
- la liste des fournisseurs, modèles et régions de traitement ;
- les comptes administrateurs et la procédure de gestion des utilisateurs ;
- les règles de conservation, d'export et de suppression ;
- la configuration du quota et des alertes ;
- un guide utilisateur et une session de formation initiale ;
- les procédures de support, d'incident et de sortie du service.
Points ouverts
- À TRANCHER (Baptiste) : partir d'une brique open source ou développer l'application de chat en interne ; si une brique est retenue, laquelle.
- À TRANCHER (Baptiste) : le fournisseur d'inférence et le modèle proposés par défaut pour chaque niveau de sensibilité.
- À TRANCHER (Baptiste) : la durée de conservation par défaut des conversations.
- À TRANCHER (Baptiste) : le mécanisme de transmission de l'identifiant utilisateur et l'affichage de la jauge d'usage dans l'application.