Un agent IA pour le design d'intérieur : Claude sans RAG ni LangChain

Un article publié sur Habr décortique un agent IA basé sur Claude qui automatise le design d'intérieur : 712 lignes de code au lieu de frameworks RAG.

De quels composants se compose l'agent ?

Les deux modèles Claude se répartissent les rôles selon le type de tâche. L'interface de chat repose sur Claude Haiku 4.5 : le modèle répond rapidement aux questions des clients, précise leur demande et mène le dialogue. Claude Sonnet 4.6 se charge de générer les concepts de design : il transforme les souhaits du client en une description structurée de l'intérieur. Les photos qui illustrent les concepts viennent de la bibliothèque Pexels, une solution nettement moins chère et plus rapide que la génération d'images via DALL-E.

Les paramètres clés de la solution :

• Claude Haiku 4.5 — dialogue avec le client : rapide et économique
• Claude Sonnet 4.6 — génération de concepts de design structurés
• Pexels API — sélection de photos à la place de DALL-E
• Un seul fichier main.py, 712 lignes de code, deux prompts système
• Aucun orchestrateur, aucune base vectorielle, aucun framework au-dessus de l'API

Cette architecture n'a rien d'un hasard. Pour un studio au budget limité et au flux de clients modeste, une stack RAG complète relève de la sur-ingénierie. Haiku coûte moins cher en dialogue ; Sonnet n'intervient que là où une génération créative structurée s'impose. Inutile de résoudre un problème d'échelle qui ne se pose pas encore.

Quels pièges l'auteur a-t-il rencontrés ?

Premier point peu évident : le seuil de mise en cache des prompts chez Claude Haiku 4.5. Le cache de contexte ne s'active qu'à partir de 4096 tokens. Si le prompt système est plus court, chaque requête est traitée comme nouvelle et la mise en cache ne fonctionne pas du tout. Sous forte charge, cela pèse sensiblement sur le coût des requêtes comme sur la latence des réponses.

Deuxième subtilité : le comportement de Sonnet 4.6 en sortie structurée. Le modèle enveloppe parfois sa réponse JSON dans un bloc de texte supplémentaire au lieu de renvoyer du JSON brut. Dans ce cas, le `json.loads()` standard plante. L'auteur a testé plusieurs stratégies de parsing et a retenu un simple wrapper avec une logique de fallback, plus fiable que de traquer le JSON à coups d'expressions régulières.

« Ce n'est pas un guide d'expert, plutôt un journal de bifurcations.

J'ai essayé d'expliquer honnêtement pourquoi j'ai pris chaque décision », explique le développeur.

La logique de séparation des modèles mérite qu'on s'y arrête. L'auteur a tenté de tout traiter avec un seul modèle, mais s'est vite rendu à l'évidence : Haiku convient là où comptent la vitesse et le coût, Sonnet là où il faut une sortie structurée de qualité. Vouloir économiser en faisant passer la génération de concepts par Haiku a donné un résultat nettement moins bon.

Où l'approche commencera-t-elle à céder ?

Le développeur pose honnêtement les limites de sa solution. Un fichier unique de 712 lignes fonctionne bien pour un MVP et un petit studio, mais le passage à l'échelle posera des problèmes :

• Avec la croissance de la clientèle, il faudra stocker l'historique des dialogues — impossible sans base vectorielle ou stockage externe
• Si le studio veut recevoir et analyser des photos envoyées par les clients, un pipeline multimodal deviendra nécessaire
• La journalisation de l'agent dans un fichier n'est pas une option avec plusieurs utilisateurs simultanés et une charge réelle
• À mesure que le projet grandit, les prompts deviennent plus difficiles à tester et à versionner dans un seul fichier

La principale conclusion de l'auteur : pour une tâche au périmètre étroit et bien défini, se passer de RAG n'est pas une solution de facilité, mais un choix d'architecture assumé. Les frameworks résolvent de vrais problèmes d'échelle, mais en créent aussi de nouveaux : complexité, dépendances, overhead d'infrastructure. Si le problème ne s'est pas encore posé, inutile de le créer pour justifier un outil.

Ce que cela signifie

La publication le montre : l'API Claude suffit pour un agent de production sans framework auxiliaire, à condition que la tâche soit suffisamment précise. Pour les développeurs qui commencent à construire des agents sur Claude, c'est un retour honnête sur des pièges bien réels : le seuil de cache de Haiku 4.5, le parsing JSON de Sonnet 4.6 et une répartition réfléchie des tâches entre des modèles de niveaux différents.

Comment utiliser Claude pour un agent de design ?

L'article présente une architecture à deux modèles : Claude Haiku 4.5 répond aux questions des clients et précise leur demande, Claude Sonnet 4.6 génère les concepts de design.

Faut-il du RAG pour un agent basé sur Claude ?

Pas nécessairement. L'agent décrit fonctionne sans framework RAG ni base de données vectorielle : tout le système tient en 712 lignes de code.

Peut-on utiliser Claude pour le design d'intérieur ?

Oui : dans ce cas d'usage, Claude Sonnet 4.6 génère les concepts de design et Claude Haiku 4.5 gère les échanges avec les clients.

Faut-il du RAG pour un agent IA basé sur Claude ?

Pas nécessairement. L'application présentée n'utilise pas de RAG : le système fonctionne avec deux prompts système et 712 lignes de code.