Les outils que Zheat utilise pour mettre des produits IA en production

Zheat met l'IA en production et la maintient. Un prototype qui marche en démo n'est pas un produit. On le transforme en quelque chose que de vrais utilisateurs peuvent utiliser, puis on reste pour la dérive, les hallucinations, et les modèles périmés.

Cette page est le registre public des outils avec lesquels on construit vraiment, pourquoi chacun est dans la stack, et quand on s'en passe. On ne vend pas une plateforme. On ne vous enferme pas dans un contrat de consulting long terme. Le code et l'infrastructure restent de votre côté.

À qui s'adresse cette stack

Cette stack s'adresse aux entreprises qui ont déjà un prototype IA, ou une idée de produit IA claire, et qui n'ont pas d'équipe d'ingénierie en interne pour le mener au lancement.

Points de départ typiques :

• Un prototype ChatGPT, Claude ou Gemini qui marche en démo et casse avec de vrais utilisateurs
• Un chatbot interne qui doit parler aux outils métier existants
• Une app React ou React Native qui a besoin d'un backend IA derrière
• Un compte AWS sans architecture prête pour la production

Si vous cherchez un marketplace de staffing, un jouet no-code, ou un retainer de consulting sur plusieurs années, ce n'est pas ça.

Comment Zheat choisit ses outils

Zheat choisit les outils pour des contraintes de production, pas pour une slide. Les questions avant d'ajouter quoi que ce soit à un projet :

1. Est-ce que ça tourne contre les APIs qu'on va vraiment shipper, pas seulement contre ChatGPT dans un navigateur ?
2. Est-ce qu'on peut observer qualité, latence et coût une fois que les utilisateurs arrivent ?
3. Est-ce que ça se connecte aux systèmes existants du client sans tout réécrire ?
4. Est-ce que le client peut le garder après notre départ ?

Si un outil rate ces tests, on ne l'utilise pas, même s'il est à la mode.

Modèles de langage : ChatGPT, Claude, Gemini et AWS Bedrock

Un modèle de langage est le composant qui génère réponses, brouillons et appels d'outils. Zheat livre contre l'API de ChatGPT, Claude, Gemini ou AWS Bedrock, pas contre une fenêtre de chat.

On prototype sur la même API qu'on mettra en production. Un prototype qui ne marche que dans l'UI de ChatGPT n'est pas un produit. L'API a une latence, un coût, des rate limits et des modes de panne différents.

Quand on utilise Bedrock : la charge vit déjà sur AWS, ou le client a besoin de modèles hébergés dans son compte cloud.

Quand on mélange les modèles : un modèle pour une classification pas chère, un autre pour la génération plus dure, avec du routage pour que la facture reste prévisible quand l'usage grandit.

Zheat a livré un assistant interne multi-modèles pour BPI France (Alfred.ia) avec GPT-4o, Claude et d'autres modèles derrière une seule surface produit.

Backends Python

Python est le langage que Zheat utilise pour la plupart du backend, le glue ML, et l'infrastructure AWS as code.

On construit des applications startup, des systèmes de contenu, des backends d'apps mobiles, des chatbots et des backends d'agents en Python depuis 2014. Le travail nouveau passe en général par FastAPI pour les APIs HTTP et AWS CDK en Python pour l'infra. On livre encore du Django quand c'est le bon fit pour une codebase existante.

Python est l'endroit où vivent les pipelines RAG, les graphes LangChain, les harnais d'éval et les contrôles de coût. Le modèle est une dépendance. Le produit est le service Python autour.

Plus de détail : Développeurs Python seniors pour l'IA, la data et AWS.

LangChain et LangGraph

LangChain est un framework pour composer appels LLM, outils, mémoire et retrieval dans une application. LangGraph est la pièce qu'on utilise quand le workflow est un graphe : branchement, retry, attente d'un humain, appel d'un autre outil.

Zheat utilise LangChain pour construire des agents : un logiciel qui prend un objectif utilisateur, appelle des outils, et revient avec un résultat, au lieu d'un chat prompt-in, texte-out.

On n'utilise pas LangChain parce que c'est à la mode. On l'utilise quand le produit doit :

• Appeler plus d'un outil en séquence
• Garder un état entre les étapes
• Échouer d'une façon qu'on peut logger, tester et rejouer

Si le job est une retrieval et une réponse, un service Python mince suffit. LangChain gagne sa place quand le prototype doit devenir un workflow que d'autres systèmes peuvent croire.

Retrieval-augmented generation (RAG)

La génération augmentée par retrieval (RAG) est un pattern qui va chercher des morceaux pertinents des données du client et les passe au modèle avant qu'il réponde. Le modèle ne devine pas seulement à partir de l'entraînement. Il répond à partir des documents, du catalogue ou de la base que le métier a déjà.

Le RAG est le correctif habituel quand un prototype « a l'air intelligent » puis invente des noms de produits, des prix ou des politiques.

Zheat construit du RAG qui doit rester juste quand le corpus grandit. Ça veut dire chunking, éval de retrieval, et un chemin pour remplacer une mauvaise source sans redéployer du folklore. On a écrit publiquement sur les cas où le RAG est le mauvais outil, catalogues d'implants brouillons et wrappers qui ne sont pas un produit RAG. Voir Le RAG est-il le bon outil pour un catalogue d'implants brouillon ? et mcp-raganything n'est pas un produit RAG.

Model Context Protocol (MCP)

Le Model Context Protocol (MCP) est un protocole ouvert pour connecter un modèle de langage à des outils et des sources de données. En production, ça veut dire que l'assistant peut utiliser les systèmes que le métier fait déjà tourner, au lieu de vivre dans un silo de chat.

Zheat utilise MCP pour brancher des LLM sur des APIs internes, de la documentation et des outils métier. On a livré des serveurs MCP, des builders MCP visuels, et des intégrations prêtes pour des agents. Meet Mila et MCP Factory sont des exemples de travail MCP productisé, pas du slideware.

MCP est la bonne couche quand le blocage est « le prototype ne voit pas notre CRM, catalogue ou tickets ». C'est la mauvaise couche quand le blocage est encore « le modèle invente » — ça, c'est d'abord un problème de RAG et d'éval.

React et TypeScript

React est la librairie que Zheat utilise pour la plupart des UI produit web. On l'écrit en TypeScript.

Le backend IA ne sert à rien si l'utilisateur ne peut pas finir le job dans l'interface. React est l'endroit où on met le produit : les écrans, l'auth, les états pour des appels modèle lents, et les replis quand le modèle a tort ou est down.

La plupart des frontends Zheat sont en React. On ne choisit pas un nouveau framework par projet. Production, ça veut dire une stack pour laquelle l'équipe du client peut recruter et qu'elle peut garder.

Plus de détail : Développeurs React.

React Native

React Native est la façon dont Zheat livre iOS et Android à partir d'une seule codebase. On l'utilise pour des portails clients, des apps retail, et d'autre mobile de production.

Si le prototype est une démo web et que les vrais utilisateurs sont sur téléphone, React Native est en général le chemin le plus court vers une app prête pour les stores, sans deux équipes natives.

Des exemples livrés sur ce site incluent MyIsuzu et MECCA, avec des partenaires, sur le même muscle React Native qu'on utilise pour de nouveaux produits IA.

Plus de détail : Développeurs React Native.

AWS, serverless et infrastructure

Amazon Web Services (AWS) est l'endroit où Zheat héberge la plupart des charges de production. La forme par défaut est serverless : Lambda, API Gateway, CloudFront, S3, plus le store de données qui va (DynamoDB ou RDS). On écrit l'infra as code avec AWS CDK en Python.

Serverless n'est pas un slogan. C'est la façon de garder la charge d'ops basse, de scaler quand les utilisateurs arrivent, et d'éviter un body shop long terme assis sur un cluster. On utilise des conteneurs sur EC2 quand la charge en a besoin.

Zheat a livré 20+ applications startup sur AWS. On utilise AWS Bedrock quand le modèle doit vivre à côté de cette infrastructure.

Plus de détail : Infrastructure AWS pour startups.

CMS headless

Un CMS headless est un système de contenu qui expose le contenu via une API au lieu de rendre le site public lui-même. Zheat utilise Contentful ou Storyblok quand le produit a des pages, des campagnes ou du contenu éditorial qu'un non-ingénieur doit changer.

On ne met pas la bibliothèque de prompts dans un CMS par défaut. Les prompts qui changent les réponses en production ont besoin de versioning et de tests, pas d'un bouton publier marketing.

Automatisation n8n

n8n est un outil de workflow que Zheat utilise pour brancher des apps et automatiser des process internes. C'est utile quand le produit doit parler à Slack, l'email, des CRM ou du back-office sans écrire une intégration custom pour chaque saut.

n8n n'est pas l'agent de production. LangChain et Python le sont. n8n est la colle autour du produit quand les operations du client vivent déjà dans un patchwork d'outils SaaS.

Comment les pièces s'assemblent

Un produit IA Zheat typique en production ressemble à ça :

1. React ou React Native est le produit que l'utilisateur touche.
2. Python sur AWS est l'API. Elle possède auth, rate limits, traces et plafonds de coût.
3. RAG charge les documents ou le catalogue du client avant que le modèle réponde.
4. LangChain / LangGraph fait tourner le travail multi-étapes et les appels d'outils.
5. MCP expose les systèmes métier existants comme outils que l'agent peut utiliser.
6. ChatGPT, Claude, Gemini ou Bedrock est le modèle derrière cette API.
7. n8n et un CMS headless n'apparaissent que si les operations ou le contenu en ont besoin.

Le prototype, c'est en général l'étape 6 et un notebook. La production, c'est les étapes 1 à 6, plus 7 si le métier dépend déjà de ces outils.

Ce que vous possédez à la fin

Zheat ne garde pas votre produit sur notre plateforme. Vous récupérez le code, les définitions d'infrastructure, et un handover. La stack ci-dessus est assez ouverte pour qu'une autre équipe senior puisse la faire tourner.

On conçoit, construit et déploie en quelques semaines. Garantie 60 jours : corrections de bugs après le lancement, remboursement si on rate le périmètre convenu. Pas de lock-in consulting long terme. Votre code, votre infra.

Si vous avez un prototype et pas d'équipe d'ingénierie pour le mener au lancement, réservez un appel scope de 30 minutes.