Bonjour a tous,
Je vous partage mon projet en cours avec Claude pour mes enceintes Alexa et me bricoler une sorte de Alexa+ sur mesure et moins cher que l’abonnement prévu.
Depuis c’est passé en déploiement et debug. La partie telegram fonctionne super. La partie vocal demande pas mal de test et d’ajustement.
Evidement la suite de ce poste a été rédigé par Claude.
Projet « Alexa, demande à Claude » — Assistant vocal IA pour homelab
Document d’étude — v1.3 — 08/03/2026
Ce document décrit l’architecture d’un assistant vocal intelligent accessible via les Echo Alexa, utilisant l’API Claude (Anthropic) avec tool use pour piloter un homelab Proxmox complet. Le projet est en phase d’étude, pas encore implémenté.
1. Objectif
Créer un assistant vocal intelligent accessible via les Echo Alexa existants, capable de répondre à des requêtes complexes sur le homelab que l’Alexa native ne peut pas traiter.
Ce que Claude apporte qu’Alexa ne sait pas faire :
- Requêtes analytiques — « Quel appareil consomme le plus en ce moment ? », « Combien d’électricité cette semaine ? », « Quelle est la tendance de température du salon sur 24h ? »
- Diagnostic — « Pourquoi la lumière de la cuisine reste allumée ? », « Est-ce que tous mes appareils Zigbee sont en ligne ? », « Y a-t-il des erreurs dans les logs Node-RED ? »
- Gestion infrastructure — « État des backups ? », « Mises à jour disponibles ? », « Combien de RAM utilise Proxmox ? », « Quel conteneur Docker consomme le plus ? »
- Actions multi-étapes — « Vérifie les appareils Z2M offline et envoie-moi la liste sur Telegram », « Fais un snapshot système et note-le dans BookStack »
- Documentation/mémoire — « Note dans BookStack que j’ai changé le filtre du purificateur », « Quel est l’état du projet thermostat ? »
Ce qui reste à Alexa (commandes directes via Matter Hub) :
- Allumer/éteindre lumières, TV, appareils
- Régler le chauffage
- Routines simples
- Timers, alarmes, musique
2. Architecture générale
┌─────────────────────────────────────────────────────────┐
│ FLUX PRINCIPAL │
│ │
│ Utilisateur : "Alexa, demande à Claude quel appareil │
│ consomme le plus" │
│ │
│ ┌─────────┐ ┌──────────────┐ ┌────────────────┐ │
│ │ Echo │───>│ Skill Alexa │───>│ Endpoint HTTP │ │
│ │ (STT) │ │ (Lambda/self)│ │ (LXC dédié) │ │
│ └─────────┘ └──────────────┘ └───────┬────────┘ │
│ ▲ │ │
│ │ ▼ │
│ │ ┌───────────────┐ │
│ │ │ Agent Claude │ │
│ │ │ (API Anthropic│ │
│ │ │ + tools) │ │
│ │ └───────┬───────┘ │
│ │ │ │
│ │ Appels tools : │ │
│ │ ┌──────┬──────┬──────┐ │ │
│ │ │ HA │ NR │ Prox │ ... │ │
│ │ └──────┴──────┴──────┘ │ │
│ │ │ │
│ │ ┌────────────────────────┐ │ │
│ └─────────│ TTS Retour │<──┘ │
│ │ (réponse Alexa ou │ │
│ │ notify.alexa_media) │ │
│ └────────────────────────┘ │
└─────────────────────────────────────────────────────────┘
Les 5 briques
| Brique | Rôle | Hébergement | Décision |
|---|---|---|---|
| 1. Agent Claude | Cerveau IA — reçoit la question, appelle les tools, formule la réponse | LXC dédié (Python) |  SDK anthropic + routeur Haiku/Sonnet |
| 2. Endpoint HTTP | Point d’entrée recevant les requêtes Alexa + Telegram | LXC dédié (FastAPI) | Service séparé, Cloudflare Tunnel |
| 3. Skill Alexa | Interface vocale — capture la question en texte libre | Lambda AWS | Lambda AWS, slot AMAZON.SearchQuery |
| 4. TTS Retour | Renvoie la réponse vocale à l’Echo | Skill + Polly + Telegram | 3 niveaux (sync/Polly audio/pré-enregistré+Telegram) |
| 5. Interface Telegram | Canal texte — même agent, réponses riches sans timeout | LXC (webhook) | Webhook Telegram → même FastAPI |
3. Brique 1 — Agent Claude (le cerveau)
3.1. Choix technique : SDK Anthropic vs Agent SDK
Comparaison détaillée
Option A — SDK Anthropic (anthropic Python package) avec tool use
- Léger, direct, contrôle total
- On définit chaque tool comme une fonction Python
- Réutilise le code existant du serveur MCP (21 outils déjà codés)
- Pas de dépendance lourde
- Adapté pour un agent rapide et focalisé
Option B — Claude Agent SDK (claude-agent-sdk)
- Framework officiel Anthropic pour construire des agents
- Support MCP natif
- Mais : embarque le CLI Claude Code (~200 Mo), plus lourd
- Conçu pour des agents complexes type développement, surdimensionné pour du vocal
Décision validée : Option A — le SDK anthropic avec tool use. Léger, rapide, et on réutilise le code Python des tools existants.
3.2. Choix du modèle
| Modèle | Input / 1M tokens | Output / 1M tokens | Vitesse | Usage |
|---|---|---|---|---|
| Haiku 4.5 | $1.00 | $5.00 | ~1-2s | Requêtes simples (état, valeur, commande) |
| Sonnet 4.5 | $3.00 | $15.00 | ~3-5s | Requêtes complexes (diagnostic, analyse) |
| Opus 4.5 | $5.00 | $25.00 | ~5-10s | Trop lent pour le vocal |
1 million de tokens ≈ 750 000 mots. Une requête vocale type ≈ 1 750 tokens, soit ~$0.002 en Haiku.
Décision validée : Routeur Haiku/Sonnet. Haiku par défaut (80% des requêtes, rapide). Escalade automatique vers Sonnet pour les requêtes complexes (diagnostics, analyses multi-sources). Les requêtes Sonnet passent en mode async (Polly audio ou Telegram).
3.3. Estimation coûts et latence API
Tableaux de coûts détaillés
Coût par requête
| Configuration | Tokens input | Haiku | Sonnet |
|---|---|---|---|
| Sans mémoire | ~1 550 | $0.002 | $0.008 |
| Mémoire 3-5 échanges (déploiement initial) | ~3 800-5 300 | $0.004-0.006 | $0.013-0.019 |
| Mémoire 10 échanges | ~9 050 | $0.010 | $0.032 |
Chaque échange mémorisé ≈ 750 tokens (question + réponse + résultat tool).
Estimation mensuelle (API Claude uniquement)
| Scénario | Sans mémoire | Mémoire 3-5 éch. | Mémoire 10 éch. |
|---|---|---|---|
| 5 req/jour (Haiku) | $0.30 | $0.60-0.90 | $1.50 |
| 20 req/jour (Haiku) | $1.20 | $2.40-3.60 | $6.00 |
| 5 req/jour (mix 80% Haiku + 20% Sonnet) | $0.66 | $1.40-2.20 | $3.70 |
| 20 req/jour (mix 80% Haiku + 20% Sonnet) | $2.64 | $5.60-8.70 | $14.80 |
Amazon Polly (niveaux 2/3) : ~$0.003/réponse en voix neurale. Négligeable (~$0.09/mois à 20 req/jour). Free tier 1M caractères/mois la première année.
Impact latence de la mémoire
| Configuration | Tokens input | Temps modèle (Haiku) | Budget restant sur 8s |
|---|---|---|---|
| Sans mémoire | ~1 550 | ~1-1.5s | ~6.5s pour les tools |
| Mémoire 3-5 échanges | ~3 800-5 300 | ~1.5-3s | ~5-6.5s pour les tools |
| Mémoire 10 échanges | ~9 050 | ~3-4s | ~4s pour les tools |
Décision validée — Déploiement initial : mémoire 3-5 échanges, avec expiration après 2-3 minutes d’inactivité. Bon compromis entre suivi conversationnel (« et hier ? ») et latence acceptable.
3.4. Tools disponibles pour l’agent
Réutilisation directe des 21 outils MCP existants (serveur FastMCP Python). Sélection par priorité :
Priorité haute (usage fréquent) :
ha_get_states— lire l’état d’entités HA (capteurs, lampes, appareils)ha_history— historique récent d’une entitéha_call_service— appeler un service HA (pour actions complexes uniquement)monitor_snapshot— état système complet (CPU, RAM, disks, services)z2m_devices— état des appareils Zigbee
Priorité moyenne (usage occasionnel) :
nr_get_flow/nr_get_node— lire les flows Node-RED (diagnostic)bookstack_read/bookstack_update— lire/écrire documentationtelegram_send— envoyer un message Telegramshell_exec— commandes shell (scripts, vérifications)
Priorité basse / restreint (sécurité) :
proxmox_exec— commandes Proxmox (lecture seule recommandé)nr_update_node/nr_deploy— modifications NR (dangereux en vocal)adguard_rewrites— modifications DNS (dangereux en vocal)
3.5. System prompt
Le system prompt doit être compact (pour le coût et la vitesse) mais suffisant :
- Identité : « Tu es l’assistant homelab, accessible via Alexa »
- Carte réseau condensée : IPs principales, noms d’appareils
- Entity IDs courants : lumières, capteurs, media_players, switches
- Règles de sécurité (ne pas éteindre l’infra, pas de commandes destructives)
- Consigne de réponse : « Réponds de façon concise et vocale (pas de markdown, pas de tableaux) »
Taille cible : 800-1200 tokens (pour garder le coût bas et la réponse rapide).
4. Brique 2 — Endpoint HTTP
4.1. Choix d’hébergement
Comparaison des options
Option A — Self-hosted via Cloudflare Tunnel
- Tout reste chez soi, pas de cloud tiers
- Cloudflare Tunnel déjà en place
- HTTPS gratuit via Cloudflare
- Dépend de la disponibilité du LXC et du tunnel
Option B — Lambda AWS
- Haute disponibilité, scaling auto
- Free tier généreux (1M requêtes/mois gratuites)
- Mais : complexité supplémentaire (déploiement, logs, IAM)
- Latence réseau Lambda → LXC (les tools sont en local)
Option C — Hybride : Lambda comme proxy, LXC comme backend
- Le skill Alexa appelle Lambda (fiable, rapide)
- Lambda forwarde au LXC via Cloudflare Tunnel
- Ajoute fiabilité mais aussi latence
Décision validée : Option A — self-hosted via Cloudflare Tunnel. Tout reste local, latence minimale. Migration hybride possible si la fiabilité pose problème.
4.2. Implémentation
- Framework : FastAPI (async natif, validation automatique, docs Swagger)
- Endpoint :
POST /alexa/ask - Auth : token dans le header + validation de la signature Alexa
- URL publique : nouveau sous-domaine via Cloudflare Tunnel
4.3. Intégration avec le serveur MCP existant
Décision validée : Serveur séparé (port distinct) — plus propre, isolation (un crash de l’agent n’impacte pas le MCP Cowork), logs séparés, redémarrages indépendants. Import des fonctions tools depuis le code MCP existant.
5. Brique 3 — Skill Alexa
5.1. Fonctionnement
- Invocation : « Alexa, [nom] [question en texte libre] » (format court, un seul mot)
- Nom d’invocation : à définir après tests voix avec le skill
- Slot :
AMAZON.SearchQuery— capture le texte libre après le nom d’invocation - Limite : 1 seul slot SearchQuery par intent, pas combinable avec d’autres slots
- Langues : disponible en français (FR)
- Mode conversation : « Alexa, ouvre [nom] » ouvre le skill en session, permettant des échanges sans re-dire le nom
5.2. Hébergement du skill
Décision validée : Lambda AWS — 20 lignes de code, gratuit (free tier), ultra-fiable. Le skill ne fait que transiter le texte. La logique lourde reste sur le LXC.
5.3. Prérequis
- Compte développeur Amazon : gratuit, https://developer.amazon.com
- ASK CLI (optionnel) : outil en ligne de commande pour déployer le skill
- Le skill peut rester en mode « développement » (non publié) et être utilisable sur ses propres Echo
5.4. Projet de référence
Le repo rodrigoscoelho/skill-alexa-chatgpt4-assistpipeline-HomeAssistant fait exactement ce pattern (Alexa → LLM → HA). Différences :
- Lui passe par HA Conversation Assist API → nous passons directement par l’API Anthropic
- Lui utilise OpenAI/ChatGPT → nous utilisons Claude avec tool use
- Son code Lambda est réutilisable comme base
6. Brique 4 — TTS Retour
6.1. Stratégie à 3 niveaux (décision validée)
Niveau 1 — Synchrone (< 8s) — Cas principal
Le skill Alexa attend la réponse de l’agent et la prononce directement en SSML (voix custom). Avec Haiku (~1-2s) + 1-2 appels tools (~1-2s), la majorité des requêtes rentrent dans cette fenêtre. C’est le chemin optimal : voix custom, pas de latence perçue.
Niveau 2 — Polly audio différé (8-15s)
Le skill répond rapidement « Un instant » (voix custom). L’agent continue en arrière-plan, génère la réponse, la passe à Amazon Polly (même voix que le skill), et joue le fichier audio sur l’Echo via media_player.play_media. Même voix, cohérence totale.
Niveau 3 — Pré-enregistré + Telegram (> 15s)
Un audio Polly pré-enregistré (« Je t’envoie la réponse sur Telegram ») est joué sur l’Echo. L’agent travaille en arrière-plan et envoie le résultat détaillé via Telegram (texte formaté). Voix cohérente + résultat lisible sur téléphone.
| Niveau | Temps | Voix | Canal réponse | Cas d’usage |
|---|---|---|---|---|
| 1. Sync | < 8s | Custom (SSML skill) |
Echo directement | « Température salon ? », « État backups ? » |
| 2. Polly | 8-15s | Custom (Polly) |
Echo via media_player | « Quel appareil consomme le plus ? » |
| 3. Telegram | > 15s | Custom (pré-enregistré) |
Telegram + Echo court | « Analyse pourquoi la cuisine reste allumée » |
6.2. Voix TTS — Contrainte SSML
Test effectué le 08/03/2026 : les balises SSML <voice name='...'> sont ignorées par AMP (Alexa Media Player). Le TTS passe systématiquement par la voix Alexa par défaut, quel que soit le SSML envoyé.
| Chemin de réponse | Voix personnalisable ? | Méthode |
|---|---|---|
| Réponse synchrone (via le skill Alexa) | Oui |
SSML <voice name='...'> dans la réponse du skill |
| Réponse async (via AMP notify) |  Non |
Voix Alexa standard uniquement |
Argument supplémentaire pour maximiser les réponses synchrones (< 8s) : meilleure UX vocale.
6.3. Variante v1.4 — Tout Polly Generative (Rémi)
Détails de la variante
Alternative étudiée : supprimer le niveau 1 (SSML sync) et passer 100% des réponses par l’API Polly Generative.
Principe : le skill dit toujours « Un instant » (voix Alexa standard), puis l’agent génère la réponse, appelle Polly Generative (voix Rémi, masculine), et joue l’audio via media_player.play_media.
Avantages :
- Voix constante : 100% des réponses en Rémi Generative (meilleure qualité disponible)
- Mot d’activation « Claude » cohérent avec la voix masculine
- Simplifié à 2 niveaux : Polly audio (< 15s) et Telegram (> 15s)
- Pas de dépendance au SSML
<voice>dans le skill
Inconvénients :
- Surcoût ~80% : Polly Generative à 30 $/1M caractères (~$0.008/réponse, ~$1.20-4.80/mois selon usage)
- Latence ajoutée : +1-2s par réponse (synthèse Polly + lecture audio) vs réponse SSML directe
- Le « Un instant » est prononcé par la voix Alexa standard (transition vocale Alexa → Rémi)
Estimation coûts combinés (Claude API + Polly Generative, mémoire 3-5 échanges) :
| Scénario | Claude API | Polly Generative | Total |
|---|---|---|---|
| 5 req/jour (Haiku) | $0.60-0.90 | $1.20 | $1.80-2.10 |
| 20 req/jour (Haiku) | $2.40-3.60 | $4.80 | $7.20-8.40 |
| 5 req/jour (mix 80/20) | $1.40-2.20 | $1.20 | $2.60-3.40 |
| 20 req/jour (mix 80/20) | $5.60-8.70 | $4.80 | $10.40-13.50 |
6.4. Services AMP disponibles
| Service | Cible |
|---|---|
notify.alexa_media_last_called |
L’Echo qui a posé la question (recommandé) |
notify.alexa_media_*_echo |
Echo spécifique (salon, studio, pop) |
notify.alexa_media_partout |
Tous les Echo |
7. Contrainte du timeout 8 secondes — Analyse détaillée
Budget temps
Alexa STT + réseau ~0.5s
Skill Lambda → LXC ~0.3s (Cloudflare Tunnel)
Agent Claude (Haiku) ~1-2s (réflexion + choix tools)
Appel(s) tool(s) ~0.5-3s (selon le nombre et la latence API)
Réponse Claude ~0.5-1s
LXC → Lambda → Alexa ~0.3s
─────────────────────────────────
Total estimé ~3-7s pour 1-2 tools
Scénarios
| Requête | Tools appelés | Temps estimé | Rentre dans 8s ? |
|---|---|---|---|
| « Température du salon ? » | ha_get_states ×1 | ~3s | Oui |
| « Quel appareil consomme le plus ? » | ha_get_states ×3-5 | ~5-6s |  Juste |
| « État des backups Proxmox ? » | proxmox_exec ×1 | ~4s | Oui |
| « Snapshot système complet » | monitor_snapshot ×1 | ~4-5s | Oui |
| « Pourquoi la cuisine reste allumée ? » | ha_get_states + ha_history + nr_get_node ×3 | ~10-15s | Non → async |
| « Appareils Z2M offline ? » | z2m_devices ×1 | ~3-4s | Oui |
Stratégie retenue
- Niveau 1 (sync) : réponse synchrone (< 8s), Haiku, 1-2 tools max → voix custom SSML
- Niveau 2 (Polly) : réponse « Un instant » + Polly audio via media_player → même voix, léger délai
- Niveau 3 (Telegram) : audio pré-enregistré Polly + envoi Telegram détaillé → voix cohérente + texte lisible
- Détection : l’agent estime le temps nécessaire avant de commencer (selon le nombre de tools) et choisit le niveau approprié
Variante v1.4 : tout Polly Generative (Rémi), 2 niveaux seulement → voir section 6.3
8. Interface Telegram (même agent, canal texte)
8.1. Principe
Le même agent Claude (mêmes tools, même system prompt, même routeur Haiku/Sonnet) est accessible par deux interfaces :
- Alexa → voix, rapide, concis, contraint par le timeout 8s
- Telegram → texte, détaillé, sans contrainte de temps
C’est une deuxième porte d’entrée vers le même cerveau, pas un agent séparé.
┌─────────────┐
│ Agent Claude │
│ (LXC dédié) │
│ + 21 tools │
└──────┬──────┘
│
┌────────────┼────────────┐
│ │
┌──────┴──────┐ ┌──────┴──────┐
│ Alexa │ │ Telegram │
│ (vocal) │ │ (texte) │
│ timeout 8s │ │ sans limite│
└─────────────┘ └─────────────┘
8.2. Réception des messages — Webhook
Webhook Telegram → LXC via Cloudflare Tunnel
- Telegram envoie chaque message au endpoint webhook
- Même service FastAPI que l’endpoint Alexa (même port, routes distinctes)
- Temps réel, pas de polling, pas de boucle permanente
8.3. Différences Alexa vs Telegram
| Alexa | Telegram | |
|---|---|---|
| Timeout | 8s strict | Aucun |
| Modèle | Routeur Haiku/Sonnet | Routeur Haiku/Sonnet (même logique) |
| Format réponse | Texte court, adapté au vocal | Texte riche, markdown, tableaux, listes |
| Consigne system prompt | « Réponds de façon concise et vocale » | « Réponds en texte, tu peux détailler et formater » |
| Mémoire | 3-5 échanges, expire 2-3 min | 3-5 échanges, expire 10-15 min |
| Tools | Mêmes 21 tools, mêmes restrictions sécurité | Idem |
| Réponse longue | Niveaux 2/3 (Polly/Telegram) | Pas de limite, réponse directe dans le chat |
8.4. Avantages du canal Telegram
- Pas de timeout → Sonnet peut travailler sur des diagnostics complexes sans pression
- Réponses riches → tableaux de consommation, listes d’appareils, historiques détaillés
- Historique visible → conversation relisible, partage facile
- Mobilité → accessible depuis n’importe où (pas besoin de VPN)
- Complémentaire à Alexa → les réponses de niveau 3 (analyses lourdes) arrivent naturellement ici
- Pièces jointes possibles → l’agent pourrait envoyer des graphiques, screenshots, fichiers à terme
8.5. Estimation coûts additionnels
Pas de coût supplémentaire d’infra : même service FastAPI, même tunnel, même agent. Seul le coût API Anthropic s’ajoute proportionnellement à l’usage.
| Scénario Telegram | Coût mensuel (routeur Haiku/Sonnet, mémoire 3-5 éch.) |
|---|---|
| 5 messages/jour | ~$0.60-2.20 |
| 10 messages/jour | ~$1.20-4.40 |
| 20 messages/jour | ~$2.40-8.70 |
Coût total combiné (Alexa + Telegram) : scénario réaliste (5 req Alexa + 10 msg Telegram / jour) ≈ $2-5/mois.
9. Sécurité
9.1. Authentification endpoint
- Token statique dans le header pour les requêtes du skill
- Validation signature Alexa : vérifier que la requête vient bien d’Amazon
- Rate limiting : max 10 requêtes/minute
9.2. Restriction des tools
Certains outils sont dangereux en accès vocal (pas de confirmation visuelle) :
| Niveau | Tools | Politique |
|---|---|---|
| Libre | ha_get_states, ha_history, monitor_snapshot, z2m_devices, bookstack_read | Lecture seule, aucun risque |
| Contrôlé | ha_call_service, telegram_send, shell_exec (lecture) | Autorisé avec filtrage |
| Restreint | nr_update_node, nr_deploy, proxmox_exec, adguard_rewrites | Lecture seule ou désactivé en vocal |
| Interdit | Commandes destructives (rm, delete, reset, reboot) | Bloqué dans le system prompt + filtrage code |
9.3. Logs et audit
- Logger chaque requête (timestamp, question, tools appelés, réponse)
- Alerte Telegram si requête suspecte ou erreur
10. Mémoire et contexte
Mémoire 3-5 échanges dès le déploiement initial
- Stocker les 3 à 5 derniers échanges dans un fichier JSON
- Les injecter dans le prompt à chaque requête
- Expiration : effacer l’historique après 2-3 minutes d’inactivité
- Permet les questions de suivi naturelles : « et hier ? », « donne-moi plus de détails », « et pour le salon ? »
- Impact coût : ×2-3 par rapport à sans mémoire
- Impact latence : +0.5-1.5s (reste compatible avec le sync < 8s)
Évolution future
- Mémoire longue (v2) : profil utilisateur persistant (préférences, pièces favorites, seuils personnalisés)
- Mémoire étendue (v3) : augmenter à 10 échanges pour les sessions de diagnostic prolongées
11. Prérequis techniques
À créer/obtenir
| Élément | Action | Coût |
|---|---|---|
| Clé API Anthropic | Créer compte sur console.anthropic.com | 5$ crédits gratuits |
| Compte dev Amazon | S’inscrire sur developer.amazon.com | Gratuit |
| Compte AWS (Lambda + Polly) | Créer compte sur aws.amazon.com | Free tier (Lambda 1M req/mois, Polly 5M chars/mois) |
SDK Python anthropic |
pip install anthropic |
Gratuit |
SDK Python boto3 |
pip install boto3 (pour Polly TTS) |
Gratuit |
Déjà en place
| Élément | État |
|---|---|
| LXC dédié avec Python 3.11 | Opérationnel |
| 21 tools MCP codés en Python | Serveur FastMCP |
| Cloudflare Tunnel | Actif |
| Services notify AMP | 6 services disponibles |
| Accès APIs HA, NR, Proxmox | Tokens configurés |
12. Plan d’implémentation (phases)
Phase 1 — Proof of Concept (agent standalone)
- Coder l’agent Python avec le SDK anthropic + 3-4 tools de base
- Tester en ligne de commande (
python3 agent.py "quelle température au salon ?") - Valider que Haiku répond correctement avec les tools
- Pas besoin d’Alexa ni d’endpoint pour cette phase
Phase 2 — Endpoint HTTP
- Ajouter FastAPI avec un endpoint
/alexa/ask - Exposer via Cloudflare Tunnel (nouveau sous-domaine ou route)
- Tester avec curl depuis l’extérieur
- Implémenter l’auth par token
Phase 3 — Skill Alexa
- Créer le compte dev Amazon
- Configurer le skill (interaction model, slot SearchQuery)
- Coder la Lambda
- Tester sur les Echo réels
- Implémenter la stratégie timeout (sync < 8s, async sinon)
Phase 4 — Enrichissement
- Ajouter tous les 21 tools
- Affiner le system prompt avec l’usage réel
- Implémenter le routeur Haiku/Sonnet
- Ajouter la mémoire conversationnelle
- Logging et monitoring
13. Risques et mitigations
| Risque | Impact | Mitigation |
|---|---|---|
| Timeout 8s dépassé | Alexa dit « pas de réponse » | Stratégie async + TTS différé |
| LXC indisponible | Skill ne répond plus | Monitoring (health-check, Uptime Kuma) |
| Coût API imprévu | Facture élevée | Haiku par défaut, rate limiting, alertes |
| Mauvaise reconnaissance vocale | Question mal transcrite | AMAZON.SearchQuery optimisé pour le texte libre |
| Sécurité endpoint | Accès non autorisé | Token + signature Alexa + rate limiting |
| Latence Cloudflare Tunnel | Ajout de délai | Mesurer, migrer vers Lambda si besoin |
14. Alternatives étudiées et écartées
| Alternative | Pourquoi écartée |
|---|---|
| HA Conversation Assist + Gemini | Trop limité : seulement l’API Assist, pas d’accès NR/Proxmox/Docker |
| Ollama local (LLM self-hosted) | Trop lent sur le hardware actuel, pas de tool use mature |
| OpenAI API | Plus cher que Haiku, pas d’avantage significatif |
| Home-3B-v3 (LLM spécialisé HA) | Pas de tool use, limité aux commandes HA simples |
15. Sources et références
- AMAZON.SearchQuery — Alexa Slot Type Reference
- Progressive Response API — Alexa Skills Kit
- Host a Custom Skill as a Web Service — Alexa Skills Kit
- Alexa Response Timeout (8s) — Alexa Skills Kit
- rodrigoscoelho/skill-alexa-chatgpt4-assistpipeline-HomeAssistant
- Anthropic API Pricing
- Claude Agent SDK
- Anthropic Python SDK — Tool Use
- Amazon Polly Features
- Amazon Polly Generative TTS Engine