Construire une fonctionnalité IA qui fonctionne dans une démo est facile. En construire une qui fonctionne de façon fiable en production — sur des entrées diverses, sous charge, avec des modes d'échec observables — nécessite un design délibéré. Ces patterns décrivent ce qui distingue le code de prototype des systèmes IA en production.
Pattern 1 : Garder l'appel LLM derrière une API
La décision architecturale la plus importante est de ne jamais appeler un LLM directement depuis votre frontend ou votre couche backend orientée utilisateur. Chaque appel LLM devrait passer par une couche d'exécution qui peut être monitorée, limitée en débit et mise à jour indépendamment.
Dans le modèle de Waiflo, c'est explicite : votre application appelle POST /api/exec/step avec le nom de l'étape et les entrées. La couche d'exécution résout le template de prompt, injecte le schéma de sortie, appelle le LLM, valide la réponse et retourne le résultat. Votre application ne touche jamais le texte du prompt ni l'API LLM directement.
Cette indirection signifie que vous pouvez mettre à jour un prompt sans déployer une nouvelle version de votre application. Vous pouvez changer de fournisseur LLM sans modifier le code d'intégration. Et vous disposez d'un seul endroit pour ajouter le logging, le suivi des coûts et la gestion des erreurs.
Pattern 2 : Streamer, pas bloquer
Les appels LLM peuvent prendre plusieurs secondes pour des prompts complexes. Bloquer l'expérience utilisateur pendant toute la durée est inutile et nuit aux performances perçues. Les Server-Sent Events (SSE) vous permettent de streamer les tokens au client au fur et à mesure qu'ils sont générés :
const source = new EventSource('/api/exec/step');
source.onmessage = e => appendToken(e.data);
source.onerror = () => source.close();L'exigence d'infrastructure clé pour SSE en production est un reverse proxy configuré pour ne pas bufferiser les réponses. Dans Nginx, cela signifie proxy_buffering off et les en-têtes X-Accel-Buffering: no appropriés. Sans cela, les tokens sont bufferisés et livrés en une fois, annulant l'intérêt du streaming.
Pattern 3 : Valider les sorties, pas seulement les entrées
La validation des entrées est une pratique standard. La validation des sorties — vérifier que la réponse du LLM est conforme à un schéma avant de l'utiliser — est moins courante mais tout aussi importante.
Un prompt qui fonctionne correctement 95% du temps n'est pas suffisant pour la production. Les 5% de réponses malformées doivent être détectées, loggées et gérées — soit en réessayant avec un prompt modifié, en retournant une réponse dégradée, ou en surfaçant une erreur claire. Sans validation des sorties, ces cas corrompent silencieusement l'état en aval.
Le ws_output_schema de Waiflo rend cette validation automatique. Le runtime injecte le schéma dans le prompt (augmentant significativement la conformité) et valide la réponse avant qu'elle soit passée à l'étape suivante.
Pattern 4 : Séparer la logique de prompt de la logique applicative
Intégrer les prompts dans le code applicatif crée un couplage implicite entre deux choses qui évoluent à des rythmes très différents. Le code applicatif change avec les releases de fonctionnalités. La logique de prompt change avec le comportement du modèle, les exigences métier et les résultats d'évaluation — souvent plus fréquemment, et souvent par des personnes différentes.
Quand la logique de prompt vit dans un fichier séparé (un workflow .waiflo.json), elle peut être mise à jour, relue et déployée indépendamment. Un chef de produit peut itérer sur le langage du prompt sans toucher au code applicatif. Un data scientist peut améliorer les schémas de sortie sans cycle de release complet.
Pattern 5 : Construire pour l'observabilité dès le premier jour
Les fonctionnalités IA ont des modes d'échec différents des bugs logiciels traditionnels. Le système ne plante pas — il retourne une réponse subtilement incorrecte d'une façon difficile à détecter automatiquement. Détecter ces échecs nécessite un investissement délibéré dans l'observabilité :
- Logguer chaque appel LLM avec ses entrées, sorties, latence et coût en tokens. Pas seulement les erreurs — tout.
- Suivre les violations de schéma de sortie comme métrique. Un taux de violation croissant est un signal précoce que le comportement du modèle a évolué.
- Exécuter des évaluations en CI sur un ensemble fixe de cas de test à chaque changement de prompt. Les régressions devraient être détectées avant d'atteindre la production.
- Versionner vos prompts pour pouvoir corréler les changements dans la qualité des sorties avec des éditions spécifiques de prompts.
Rien de nouveau ici. Ce sont les mêmes pratiques d'observabilité qui s'appliquent à tout système distribué, adaptées aux modes d'échec spécifiques des composants basés sur LLM. Les équipes qui construisent des fonctionnalités IA fiables les traitent comme des problèmes d'ingénierie logicielle avec une composante probabiliste — pas comme de la magie qui fonctionne ou ne fonctionne pas.