Pipeliner Client

> **Idée / spike de cadrage — ce ticket n'est PAS une spécification.** Il capture une intuition produit et l'audit de coût qui la motive. Une phase de conception est nécessaire avant toute implémentation.

## Idée (formulation du product owner)

Permettre aux clients de **contourner l'assistant IA intégré** et d'utiliser **leur propre IA** pour interagir directement avec Redmine. Bénéfice attendu : **transférer le coût des appels LLM au client**.

Pistes évoquées, non tranchées :

- exposer un **serveur MCP** ;
- une configuration de type **« dossier secret »** avec identifiants (piste jugée délicate : un client est sur Microsoft) ;
- une approche par **partage de mémoire / de contexte**.

## Contexte — audit de coût (réalisé le 2026-07-20)

L'audit du code confirme la prémisse économique du PO :

- **Déposer un ticket ne déclenche aucun appel LLM.** C'est du pur I/O Redmine (`api/src/client_dashboard/application/create_ticket_from_draft.py`). **Tout** le coût IA est engagé **en amont**, dans la conversation qui produit le draft.
- L'assistant **rejoue l'intégralité de l'historique de conversation, sans borne, à chaque tour** (`api/src/client_dashboard/application/stream_assistant_reply.py:123-147`), auquel s'ajoutent un préfixe fixe d'environ **2 330 tokens** (persona système + 6 chunks RAG) et **chaque analyse de pièce jointe inlinée en entier**. Aucun fenêtrage, aucune troncature, aucune synthèse, aucun prompt caching.
- Le coût est donc **quadratique en nombre de tours** : ~2 400 tokens d'entrée au tour 1, ~20 800 au tour 50, soit **~580 000 tokens cumulés** sur une conversation de 50 tours.
- Modèles utilisés (`api/src/client_dashboard/infrastructure/config.py:49-55`) : `mistral-large-latest` (chat + génération de draft), `mistral-small-latest` (vision), `mistral-ocr-latest` (PDF), `mistral-embed` (retrieval).
- **Aucune comptabilisation de tokens ni d'usage n'existe aujourd'hui** : le bloc `usage` retourné par Mistral est ignoré à tous les points d'appel. Le coût IA **ne peut donc pas être attribué par client** en l'état.
- Ordre de grandeur : **~0,11 $ pour une session de 10 tours**, **~1,30 $ pour 50 tours**.

**Conclusion :** le BYO-IA déplacerait bien le coût variable dominant vers le client, alors que ce que nous facturons réellement (dépôt de ticket, livraison) reste inchangé.

## Questions ouvertes (à trancher en conception)

- **Quelle surface exposer ?** Un serveur MCP exposant les opérations Redmine du dashboard, cadrées par projet ; un accès direct à l'API Redmine par client ; ou autre chose.
- **Authentification et cloisonnement multi-tenant.** Un client BYO-IA doit être strictement confiné à ses propres projets. L'autorisation vit aujourd'hui dans la couche API du dashboard : la contourner impose de **réimplémenter cette frontière** sur la nouvelle surface exposée.
- **Contrainte Microsoft / Entra** signalée par le PO : un client s'authentifie via Entra SSO (travaux en cours sur la branche `feature/1311-entra-sso`, cf. #1311), ce qui complique une approche à identifiants statiques type « dossier secret ».
- **Perte du contexte projet (RAG).** L'assistant intégré injecte de la connaissance projet retrouvée par recherche sémantique, dont l'IA du client ne disposerait pas. Le BYO-IA doit-il avoir un accès en lecture à la base de connaissance, et qu'est-ce que cela implique en matière de **confidentialité** ?
- **Implications de facturation.** Les crédits ne sont consommés qu'au **dépôt** du ticket : un client BYO-IA resterait donc facturé normalement. Mais cela supprime l'alignement d'incitations et doit être vérifié contre le modèle de formules (#1147).
- **Positionnement commercial :** le BYO-IA est-il un avantage de formule, une remise, ou ouvert à tous ?

## Prochaine étape

Cadrage / conception. Aucun développement avant arbitrage sur la surface exposée et sur le modèle d'autorisation.

## Classification
- feature