refactor(ia): unifier le contrat de AI_BASE_URL entre les providers #17

New Issue

AntoineVe · 2026-09-09T00:08:59+02:00

AntoineVe commented

2026-09-09 00:08:59 +02:00

Constat

AI_BASE_URL est interprétée par plusieurs providers, mais la validation et les prérequis ne sont pas centralisés. Le provider openai-compatible possède une vérification dédiée, tandis que openai et litellm suivent d'autres chemins de construction.

Cette dispersion rend difficile de savoir, depuis la configuration et le wiki, quelles valeurs sont acceptées par quel provider. Elle favorise également les écarts futurs entre les tests, le comportement réel et la documentation.

Proposition

Définir un contrat unique pour toute valeur AI_BASE_URL personnalisée, le faire appliquer par les trois chemins de factory et documenter les particularités qui restent nécessaires par provider (modèle requis, URL par défaut, chemin d'API attendu).

Conserver deux garanties existantes : la factory ne fait pas de requête réseau et une configuration invalide se dégrade proprement sans fuite dans les diagnostics.

Critères d'acceptation

Les trois providers appliquent la même validation de base à une URL personnalisée.
Les prérequis propres à chaque provider sont explicites, couverts par tests et documentés.
Les erreurs et warnings sont homogènes et ne révèlent pas les valeurs sensibles.
Aucun ajout automatique de chemin d'API n'est effectué sans contrat documenté.
Le wiki IA, .env.example et les tests de factory reflètent le comportement livré.

Périmètre

Factory de synthèse IA, configuration et documentation ; aucun nouveau provider ni appel réseau réel.

## Constat `AI_BASE_URL` est interprétée par plusieurs providers, mais la validation et les prérequis ne sont pas centralisés. Le provider `openai-compatible` possède une vérification dédiée, tandis que `openai` et `litellm` suivent d'autres chemins de construction. Cette dispersion rend difficile de savoir, depuis la configuration et le wiki, quelles valeurs sont acceptées par quel provider. Elle favorise également les écarts futurs entre les tests, le comportement réel et la documentation. ## Proposition Définir un contrat unique pour toute valeur `AI_BASE_URL` personnalisée, le faire appliquer par les trois chemins de factory et documenter les particularités qui restent nécessaires par provider (modèle requis, URL par défaut, chemin d'API attendu). Conserver deux garanties existantes : la factory ne fait pas de requête réseau et une configuration invalide se dégrade proprement sans fuite dans les diagnostics. ## Critères d'acceptation - Les trois providers appliquent la même validation de base à une URL personnalisée. - Les prérequis propres à chaque provider sont explicites, couverts par tests et documentés. - Les erreurs et warnings sont homogènes et ne révèlent pas les valeurs sensibles. - Aucun ajout automatique de chemin d'API n'est effectué sans contrat documenté. - Le wiki IA, `.env.example` et les tests de factory reflètent le comportement livré. ## Périmètre Factory de synthèse IA, configuration et documentation ; aucun nouveau provider ni appel réseau réel.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: AntoineVe/college-infos#17