Roster pour OpenAI
Utilisez les modèles OpenAI pour déterminer qui doit agir.
Configurez un modèle OpenAI comme moteur de résolution de Roster pour interpréter les questions de workflow, identifier les participants pertinents et produire des réponses structurées et auditables.
Votre déploiement contrôle le compte OpenAI, la clé API, le modèle, l'effort de raisonnement et le processus d'approbation en production.
Dernière vérification : 13 juillet 2026
OpenAI interprète la question. Roster gouverne la réponse.
Roster maintient le contexte organisationnel :
“Qui doit approuver le renouvellement fournisseur Atlas pour l'Europe ?”
Le modèle OpenAI aide Roster à interpréter les requêtes en langage naturel. Roster reste responsable de la constitution du contexte autorisé, de la validation de la réponse du modèle, de la résolution des participants sélectionnés et de l'enregistrement de la requête.
- Projets
- Participants
- Utilisateurs et groupes
- Appartenance à l'annuaire
- Rôles et libellés
- Métadonnées des participants
- Délégations actives
- Périmètres d'accès
Le modèle ne remplace ni le modèle de participants de Roster, ni sa couche d'autorisation.
Comment l'intégration fonctionne
Roster prépare le contexte participant autorisé, appelle l'API Responses d'OpenAI avec un schéma structuré, et valide la sélection retournée avant d'associer la réponse aux utilisateurs, groupes, rôles ou délégués actifs.
Agent, workflow ou application
↓
Roster Resolve
↓
Contexte projet et participant autorisé
↓
API Responses OpenAI
↓
Sélection de participant structurée
↓
Utilisateurs, groupes, rôles ou délégués actifsPourquoi utiliser OpenAI avec Roster ?
Configurer OpenAI
OpenAI est la famille de fournisseurs de modèle par défaut de Roster.
OPENAI_API_KEY=<clé-api-openai>
OPENAI_BASE_URL=https://api.openai.com/v1
ROSTER_MODEL_PROVIDER=openai
ROSTER_MODEL_NAME=gpt-5.6-sol
ROSTER_MODEL_EFFORT=lowOPENAI_BASE_URL est optionnel si vous utilisez le point d'accès public standard d'OpenAI. Ne le définissez que pour un proxy approuvé, un point régional ou une passerelle de modèle compatible.
Stockez la clé API dans le gestionnaire de secrets de votre déploiement ou un environnement d'exécution protégé. Ne l'engagez pas dans le contrôle de version.
Qualité maximale — recommandé pour un routage complexe et à fort impact :
ROSTER_MODEL_NAME=gpt-5.6-solCoût et qualité équilibrés — résolution en production quotidienne :
ROSTER_MODEL_NAME=gpt-5.6-terraCharges à fort volume sensibles au coût — à valider avec des données représentatives avant un routage à fort impact :
ROSTER_MODEL_NAME=gpt-5.6-lunaNe choisissez pas un modèle sur la seule base des benchmarks généraux. Testez-le avec les projets, structures de participants, motifs de requête, ambiguïté et garde-fous attendus dans votre propre déploiement.
Reasoning effort — Roster accepte : none, minimal, low, medium, high, xhigh, max. Le support réel dépend du modèle. Utilisez un effort plus faible pour les requêtes simples, à fort volume et sensibles à la latence. Envisagez un effort plus élevé quand plusieurs responsabilités peuvent correspondre, que la requête comporte plusieurs contraintes, ou que le routage a un impact financier, juridique, sécurité ou opérationnel.
Exemple de résolution
Un workflow achats demande :
“Qui doit approuver le renouvellement logiciel Atlas pour l'Europe lorsque le contrat dépasse le seuil régional ?”
- Roster identifie le contexte projet Atlas autorisé.
- Roster fournit les participants, libellés, métadonnées, appartenances et délégations pertinents.
- Roster envoie la tâche de résolution structurée au modèle OpenAI configuré.
- Roster valide la sélection de participant retournée.
- Roster étend le participant sélectionné en utilisateurs, groupes ou délégués actifs.
- Roster enregistre la requête Resolve et l'exécution du modèle.
Le workflow utilise ensuite son système d'approbation existant pour contacter le participant sélectionné. Roster détermine qui doit agir — il n'envoie ni n'impose l'approbation lui-même.
Sortie structurée et observabilité
La résolution des participants n'est pas une génération de texte conversationnel ordinaire. Roster a besoin de réponses parsables de manière fiable, validables contre des champs attendus, reliables aux IDs de participants existants, vérifiables pour détecter des sélections non supportées et auditables après coup.
Les Structured Outputs d'OpenAI contraignent les réponses à un schéma JSON défini, réduisant le risque de champs manquants ou de valeurs invalides. Une connexion API réussie ne suffit pas — le modèle doit produire des réponses structurées stables sur la charge Resolve attendue.
Roster enregistre le fournisseur, le nom du modèle, le statut d'exécution, le mode live ou test, la latence, les tokens (entrée/sortie/total), le coût estimé, l'effort de raisonnement, l'ID de requête Resolve, l'ID de requête fournisseur, les identifiants de trace, les erreurs et (selon les paramètres PII) les payloads d'entrée et de sortie. Les administrateurs peuvent utiliser les Exécutions de modèle pour comparer les choix de modèle et investiguer latence, erreurs, coût et comportement de résolution.