Il y a un moment qui arrive à presque toutes les équipes qui construisent un agent IA pour la première fois. La démo fonctionne parfaitement. L’agent répond aux questions, utilise des outils, se souvient du contexte. Vous le montrez aux parties prenantes et elles sont impressionnées. Puis quelqu’un demande : “On peut mettre ça en production ?”
Cette question révèle un écart que la plupart des équipes sous-estiment. Les agents de démo sont construits pour fonctionner une fois, dans un environnement contrôlé, avec un développeur qui surveille. Les agents de production doivent fonctionner des milliers de fois, dans des conditions imprévisibles, sans personne qui surveille. L’écart entre ces deux exigences est là où la plupart des projets d’agents IA calent — et là où le choix du runtime commence à vraiment compter.
Le piège de la démo
Le piège de la démo est séduisant parce que les démos sont vraiment faciles à construire. Les frameworks IA modernes rendent trivial le fait de connecter un modèle de langage, de lui donner des outils, et de lui faire répondre à des questions. La partie difficile n’est pas de le faire fonctionner — c’est de le faire continuer à fonctionner.
Les agents de démo sont typiquement sans état. Redémarrez-les et rien n’est perdu, parce que rien n’a été sauvegardé. Ils n’ont pas d’authentification, parce que le développeur qui fait la démo est de confiance. Ils n’ont pas de limitation de débit, parce qu’il n’y a qu’un seul utilisateur. Ils n’ont pas de surveillance, parce que le développeur peut voir ce qui se passe. Ils n’ont pas de gestion d’erreurs, parce que le chemin heureux est tout ce qui compte pour la démo.
La production démonte chacune de ces hypothèses. Les utilisateurs perdent le contexte quand l’agent redémarre. Des utilisateurs non autorisés trouvent le point de terminaison. Quelqu’un envoie mille messages en une minute. L’agent donne une mauvaise réponse et personne ne sait pourquoi. Le fournisseur IA tombe et l’agent plante au lieu de se dégrader gracieusement. Chacun de ces modes d’échec est prévisible — et chacun nécessite des décisions architecturales délibérées pour être géré correctement.
Les équipes qui naviguent avec succès cette transition sont celles qui traitent les agents IA comme de l’infrastructure dès le départ, pas comme des scripts qui appellent une API.
Ce que la production exige vraiment
La première exigence est un état persistant et fiable. Un agent de production gère des conversations en cours, des préférences utilisateur accumulées, des files de tâches et du contexte appris. Cet état doit survivre aux redémarrages, aux crashs, et être récupérable quand quelque chose tourne mal. Il a besoin d’écritures atomiques — pas d’entrées de mémoire à moitié écrites qui corrompent le contexte de l’agent. Il doit être inspectable, pour que quand l’agent se comporte de façon inattendue, vous puissiez regarder ce qu’il savait et pourquoi il a pris la décision qu’il a prise.
ZeroClaw gère ça avec SQLite en mode WAL : conforme ACID, fichier unique, survit aux coupures de courant. L’état complet de l’agent vit dans un seul fichier. La sauvegarde, c’est `cp memory.db memory.db.bak`. La restauration, c’est `cp memory.db.bak memory.db`. Pas de serveur de base de données à gérer, pas de pool de connexions à configurer, pas de réplication à mettre en place. Pour les patterns d’accès que les agents IA utilisent réellement — des milliers de souvenirs, pas des millions — SQLite surpasse les bases de données distribuées parce qu’il n’y a pas d’aller-retour réseau.
La deuxième exigence est un modèle de sécurité qui ne repose pas sur la confiance. Les agents de production gèrent de vrais identifiants, accèdent à de vrais systèmes de fichiers, et interagissent avec de vrais utilisateurs qui chercheront des failles. Le modèle de sécurité ne peut pas être “faire confiance au développeur de plugin” ou “supposer que les utilisateurs se comportent bien”. Il doit être refus-par-défaut : chaque outil, chaque chemin de fichier, chaque point de terminaison réseau doit être explicitement autorisé avant que l’agent puisse y accéder. La journalisation d’audit doit enregistrer chaque exécution d’outil avec ses entrées et sorties, pour que quand quelque chose tourne mal, vous ayez une trace à suivre.
C’est précisément là où l’architecture d’OpenClaw a échoué en 2026. Le modèle de confiance WebSocket, les permissions de skills au niveau OS, et le marché de plugins avec 41,7 % d’entrées vulnérables n’étaient pas des bugs — c’étaient des décisions architecturales qui avaient du sens pour un outil de développeur et sont devenues des responsabilités quand cet outil a été déployé comme infrastructure de production gérant de vrais identifiants et de vraies données.
La troisième exigence est l’observabilité. Quand un agent donne une mauvaise réponse en production, “il a utilisé le mauvais contexte” n’est pas un diagnostic utile. Vous avez besoin du traçage des requêtes de la réception du message à la livraison de la réponse, du suivi de l’utilisation des tokens par conversation et par utilisateur, des logs d’exécution des outils avec entrées et sorties, et des logs de récupération de mémoire montrant exactement quel contexte a été injecté dans chaque requête. Sans ça, déboguer les problèmes de production est du tâtonnement — et tâtonner à 2h du matin quand quelque chose est cassé est coûteux.
La fiabilité est la quatrième exigence, et elle est plus nuancée que “ne pas planter”. La production signifie des attentes de disponibilité 24/7, ce qui implique un redémarrage automatique en cas de crash, une dégradation gracieuse quand le fournisseur IA est indisponible, une reconnexion avec backoff exponentiel pour les canaux, et des points de terminaison de health check pour les systèmes de surveillance. Cela signifie aussi un temps de démarrage à froid qui ne crée pas d’interruptions visibles pour les utilisateurs. Un agent qui prend 8 secondes à redémarrer crée une fenêtre d’indisponibilité qui, sur un an, s’accumule en heures de temps d’arrêt. Un agent qui redémarre en 10 millisecondes est effectivement toujours disponible.
La cinquième exigence est le contrôle des coûts. Les agents IA non contrôlés brûlent des tokens de façon difficile à prévoir. Un seul utilisateur qui découvre qu’il peut avoir de longues conversations avec votre agent peut générer des centaines d’euros de coûts API en une journée. La production nécessite des budgets de tokens par utilisateur et par canal, une limitation de débit pour prévenir les abus, et le routage de modèles — modèles bon marché pour les requêtes simples, modèles coûteux pour les complexes. Sans ces contrôles, vos coûts en tokens vous surprendront, et pas agréablement.
Ce que la plupart des frameworks ratent
Le schéma est cohérent dans les frameworks qui n’ont pas été conçus pour la production : ils optimisent pour la démo et sous-investissent dans tout le reste.
Le chemin heureux reçoit toute l’attention. “Regardez, mon agent peut chercher sur le web et écrire du code”. La gestion des erreurs obtient un try-catch qui log dans la console. La logique de retry est laissée comme exercice pour le lecteur. La dégradation gracieuse est un commentaire TODO. Quand le fournisseur IA retourne un 429, l’agent plante au lieu de mettre la requête en file et de réessayer avec backoff. Ce ne sont pas des cas limites — ce sont les conditions normales de fonctionnement de tout service qui tourne assez longtemps.
L’efficacité des ressources est traitée comme un nice-to-have plutôt que comme un multiplicateur de coût. Un framework qui utilise 1 Go de RAM pour une seule instance d’agent ne peut pas échelle vers des déploiements multi-tenants sans infrastructure coûteuse. Si vous voulez donner à chacun de vos clients entreprise sa propre instance d’agent dédiée — ce qui est souvent la bonne architecture pour l’isolation des données — vous avez besoin d’un serveur qui peut faire tourner des centaines d’instances simultanément. À 1 Go par instance, c’est une facture d’infrastructure de 10 000 €/mois. À 4 Mo par instance, c’est un VPS à 50 €/mois.
L’histoire de production de ZeroClaw
ZeroClaw a été conçu pour la production dès le départ, et les décisions de conception le reflètent. Un binaire unique signifie que le déploiement consiste à copier un fichier de 12 Mo — pas de résolution de dépendances, pas de conflits de versions, pas de “ça marche sur ma machine”. L’empreinte de 4 Mo de RAM signifie que vous pouvez faire tourner 50 instances d’agent sur un seul VPS de 1 Go, rendant les déploiements multi-tenants économiquement viables à une échelle qui nécessiterait un serveur dédié avec tout autre runtime. Le démarrage à froid en moins de 10 ms signifie que les redémarrages sont invisibles pour les utilisateurs et que les mises à jour progressives ne causent aucune interruption.
La sécurité mémoire de Rust élimine des classes entières de vulnérabilités à la compilation — les dépassements de tampon, les use-after-free, les courses de données sont des erreurs de compilation, pas des surprises à l’exécution. Le modèle de liste d’autorisation refus-par-défaut signifie que chaque outil, chemin de fichier et point de terminaison réseau doit être explicitement autorisé dans config.toml avant que l’agent puisse y accéder. SQLite avec le mode WAL vous donne un état conforme ACID dans un seul fichier sans serveur de base de données à gérer. L’image Docker distroless ne contient que le binaire ZeroClaw et les certificats nécessaires — pas de shell, pas de gestionnaire de packages, surface d’attaque minimale.
La checklist de production
Pour les équipes qui passent des agents IA en production, la checklist porte moins sur les fonctionnalités que sur la maturité opérationnelle. Définissez les permissions des outils explicitement avant de lancer — à quoi l’agent peut-il accéder, et qu’est-ce qui lui est explicitement refusé ? Définissez des budgets de tokens par utilisateur et par canal avant d’être surpris par une facture. Configurez la surveillance et les alertes sur les taux d’erreur et les percentiles de latence. Mettez en place des sauvegardes automatiques de la base de données mémoire. Testez les scénarios d’échec délibérément : que se passe-t-il quand le fournisseur IA est en panne ? Quand le canal se déconnecte ? Quand le disque est plein ? Documentez les capacités et les limites de l’agent pour les utilisateurs finaux. Établissez un processus de réponse aux incidents pour les comportements anormaux de l’agent avant d’en avoir besoin.
L’écart entre démo et production est la maturité opérationnelle. Le framework que vous choisissez détermine combien de cette maturité est intégrée versus boltée dessus. Un runtime conçu pour la production dès le premier jour vous donne une fondation sur laquelle construire. Un runtime conçu pour les démos, retrofité avec des fonctionnalités de production, vous donne une charge de maintenance qui s’accumule avec le temps. Le choix que vous faites au début façonne tout ce qui vient après.