---
id: "0c1f1991-b6db-47b7-bbef-2478bc7874ab"
number: 14
title: "Integration de profils IA locaux/LAN comme profils IdeA canoniques"
status: "qa"
priority: "medium"
sprint: null
links: []
agentRefs: [{"agentId":"a6ced819-b893-4213-b003-9e9dc79b9641","role":"assigned"}]
createdBy: {"kind":"user"}
updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
createdAt: 1783184495846
updatedAt: 1783456579694
version: 7
---
Objectif : permettre à IdeA d'utiliser des modèles hébergés localement ou sur le réseau local, par exemple Qwen via Ollama ou un runtime Docker exposant une API, avec le même niveau d'intégration produit que les profils Claude Code et OpenAI Codex CLI.

La finalité n'est pas un simple profil custom lancé dans un terminal brut. Ces profils doivent devenir de vrais profils IA IdeA : sélectionnables, lançables depuis les cellules, pilotés par la conversation headless canonique, compatibles avec les mécanismes de conversation/reprise, et utilisables par l'orchestration de la même manière que Claude/Codex.

## Cible produit

Ajouter une famille de profil structuré pour serveurs de modèles locaux ou LAN, idéalement basée sur une API HTTP compatible OpenAI/Ollama :

- endpoint configurable (`localhost`, machine LAN, container Docker, etc.) ;
- modèle configurable (`qwen...`, autre modèle local) ;
- authentification optionnelle via nom de variable d'environnement, jamais clé en clair ;
- profil visible et sélectionnable dans IdeA comme Claude/Codex ;
- cellule IdeA utilisable de façon canonique : conversation headless, historique, reprise, délégation, affichage des réponses et état de vivacité.

## Contraintes importantes

- Ne pas considérer le mode PTY/TUI comme suffisant pour ce ticket.
- Éviter une dépendance obligatoire à `ollama`, `docker` ou une commande shell quand une API HTTP suffit.
- Étudier explicitement les impacts commandes/headless :
  - adapter HTTP natif ;
  - wrapper CLI éventuel ;
  - Docker/LAN ;
  - sandbox et permissions ;
  - absence ou présence de tool-calling/MCP côté modèle local.
- Le résultat doit s'intégrer dans le modèle existant `StructuredAdapter` / `AgentSessionFactory`, pas contourner le runtime IA d'IdeA.

## Travail attendu

1. Ajouter un adapter structuré pour modèle local/LAN, par exemple `StructuredAdapter::OpenAiCompatible` ou `LocalChat`.
2. Étendre le modèle de profil pour porter la configuration nécessaire : endpoint, model, apiKeyEnv optionnel, timeouts/liveness si nécessaire.
3. Implémenter une session headless `AgentSession` :
   - `send(prompt)` ;
   - émission de `ReplyEvent` ;
   - gestion propre des erreurs réseau/modèle ;
   - conversation id ou stratégie de reprise compatible avec le modèle IdeA.
4. Brancher l'adapter dans `StructuredSessionFactory`.
5. Rendre ces profils sélectionnables dans le wizard/settings au même titre que Claude/Codex.
6. Ajouter un profil de référence local, par exemple “Ollama / OpenAI-compatible local model”, éditable.
7. Vérifier l'intégration avec :
   - lancement depuis une cellule ;
   - conversation headless ;
   - reprise ;
   - changement de profil ;
   - délégation inter-agents quand applicable ;
   - état de vivacité/timeout ;
   - erreurs endpoint indisponible/modèle absent.

## Critères d'acceptation

- Je peux configurer un profil Qwen hébergé via Ollama ou endpoint LAN.
- Je peux créer/lancer un agent IdeA avec ce profil comme avec Claude/Codex.
- La cellule utilise le chemin headless structuré, pas un terminal brut PTY.
- Les conversations apparaissent et se comportent comme les conversations Claude/Codex.
- La reprise ne mélange pas l'id logique IdeA avec un éventuel id provider.
- Un endpoint indisponible produit une erreur propre dans l'UI, sans bloquer IdeA.
- Les dépendances à `ollama`, Docker ou une CLI externe sont documentées et non imposées si le mode HTTP suffit.
- Tests backend couvrant factory, session adapter, erreurs HTTP et sérialisation du profil.
- Tests frontend couvrant configuration/sélection du nouveau profil.

Review agent-user requise avant démarrage d'implémentation pour figer le périmètre exact : HTTP natif uniquement, support d'un wrapper CLI, et niveau attendu de tool-calling/MCP pour les modèles locaux.
