SmythOS SRE : un noyau d'exécution pour agents, entre SDK et système d'exploitation

Le problème visé : recâbler les mêmes ressources à chaque projet

Un agent en production touche rarement une seule brique. Il lui faut un modèle, un endroit où écrire des vecteurs, un cache pour éviter de rappeler le modèle, un coffre pour les identifiants. Le README de SRE part d'un constat simple : ces ressources ont chacune leur SDK, leurs noms de paramètres, leur gestion d'erreurs. Changer de fournisseur de stockage ou de base vectorielle revient souvent à réécrire du code métier qui n'a rien à voir avec le stockage. SRE propose de traiter ce problème au niveau du runtime plutôt que dans chaque application. Le projet se présente comme le noyau d'un système d'exploitation pour agents, avec une couche d'abstraction où tous les fournisseurs exposent les mêmes fonctions. Le public visé est précis : des développeurs TypeScript qui construisent des agents destinés à tourner en local, dans le cloud ou en périphérie, et qui veulent que le passage d'un environnement à l'autre ne change pas la logique de l'agent. La promesse est donc moins celle d'un framework d'agents supplémentaire que celle d'une couche de ressources partagée sous les frameworks existants.

Un monorepo en trois paquets, avec un noyau et un SDK séparés

La structure du dépôt est explicite. packages/core contient le SRE proprement dit, décrit comme le noyau qui gère le cycle de vie des agents, la mémoire, le stockage et le calcul. packages/sdk expose l'interface destinée au développeur. packages/cli fournit l'outil en ligne de commande. Cette séparation a une conséquence pratique : le noyau peut évoluer sans casser l'API du SDK, et inversement. Elle a aussi un coût : deux surfaces de documentation distinctes, l'une pour le SDK, l'autre pour le core, ce que le README reflète en proposant deux liens séparés vers smythos.github.io/sre/sdk et smythos.github.io/sre/core. Le noyau annonce une architecture modulaire avec des connecteurs enfichables par type de service. Les catégories listées sont le stockage (local, S3, Google Cloud, Azure), les LLM (OpenAI, Anthropic, Google AI, AWS Bedrock, Groq, Perplexity), les bases vectorielles (Pinecone, Milvus, RAMVec), le cache (RAM, Redis) et les coffres (fichier JSON, AWS Secrets Manager, HashiCorp). Le README mentionne également plus de quarante composants dits prêts pour la production, sans en donner la liste dans l'extrait disponible.

Le système Candidate/ACL, ou la sécurité placée dans le noyau

Le point le plus intéressant du dépôt n'est pas la liste des connecteurs, c'est la manière dont les accès sont contrôlés. Le README décrit un système Candidate/ACL intégré au noyau, présenté comme le mécanisme d'accès sécurisé aux ressources. L'idée sous-jacente est qu'une bibliothèque qui détient des clés d'API, des identifiants S3 et des jetons de coffre devient elle-même une surface d'attaque. Placer le contrôle au niveau du runtime plutôt que dans le code appelant déplace le problème : ce n'est plus à chaque agent de vérifier ce qu'il a le droit de toucher. Le README ne détaille pas la grammaire des règles ACL, ni la façon dont un Candidate est déclaré, ni ce qui se passe quand une règle est refusée. C'est une lacune réelle pour qui doit évaluer le modèle de menace. On peut seulement constater que le mécanisme existe, qu'il est décrit comme intégré et non optionnel, et que la documentation du core est l'endroit où chercher les détails. Tant que ces détails ne sont pas vérifiés, considérer ce point comme une intention de conception, pas comme une garantie.

Démarrer : CLI globale ou SDK dans un projet existant

Le README donne deux chemins. Le premier installe l'outil en ligne de commande globalement puis lance un assistant de création : npm i -g @smythos/cli, puis sre create. L'assistant pose des questions et génère un projet SDK avec la configuration correspondante. Le second chemin ajoute le SDK à un projet déjà en place : npm install @smythos/sdk. Le README renvoie ensuite vers le dossier examples du dépôt, vers la documentation du SDK et vers un dépôt séparé de modèles de code, SmythOS/sre-project-templates. Un détail utile pour le débogage figure dans le README : en cas de problème avec la CLI ou avec le code, définir la variable d'environnement LOG_LEVEL sur "debug", relancer, puis partager les journaux. C'est le seul réglage de configuration nommé explicitement dans l'extrait fourni. Aucune version publiée n'a été récupérée, donc rien ne permet de dire quelle version du paquet npm correspond à quel état du dépôt. Le dernier push sur la branche main date du 3 avril 2026, ce qui indique une activité récente sans rien dire de la stabilité des API.

Ce que le README ne dit pas, et qui compte

Trois silences méritent d'être signalés. D'abord, aucune trace de gestion de version des API ni de politique de compatibilité entre versions du SDK. Pour une couche qui s'insère entre votre code et vos fournisseurs, c'est la question qui détermine le coût de mise à jour. Ensuite, le fonctionnement interne de l'orchestration d'agents est mentionné comme une fonctionnalité du noyau, sans description du modèle d'exécution : processus séparés, boucle d'événements unique, file d'attente, rien n'est précisé dans l'extrait. Enfin, l'expression "battle-tested" apparaît dans la liste des bénéfices sans qu'aucune donnée ne l'étaye dans le matériel fourni. Un runtime qui abstrait le stockage, le cache et les modèles ajoute forcément une couche entre votre code et le fournisseur. Quand un appel échoue, la question devient : est-ce le fournisseur, le connecteur, ou le noyau ? Le README ne décrit pas d'outil de traçabilité propre à cette distinction, même si l'observabilité est citée parmi les éléments intégrés. C'est le genre de détail qui se découvre à l'usage, pas à la lecture.

Face à LangChain ou à une orchestration maison

La comparaison la plus directe se fait avec LangChain, dont les thématiques du dépôt se réclament explicitement. La différence d'approche est nette. LangChain organise le travail autour de chaînes et d'abstractions de composition : on assemble des étapes, et les intégrations de fournisseurs sont des paquets greffés sur cette composition. SRE se place un cran plus bas, au niveau des ressources elles-mêmes : stockage, cache, base vectorielle, coffre, modèle. Le README insiste sur le fait que l'interface reste identique d'un fournisseur à l'autre, ce qui permet selon lui de changer de fournisseur sans modifier la logique métier. C'est un pari différent. Une équipe qui a déjà une orchestration maison et veut seulement arrêter de réécrire ses appels S3 et Redis trouvera dans SRE une couche plus proche de son besoin qu'un framework de chaînes. À l'inverse, une équipe qui attend des primitives de composition d'agents très élaborées devra vérifier ce que le SDK expose réellement, car l'extrait du README ne détaille pas cette partie. Le second point de comparaison est le studio visuel du même éditeur, SmythOS Visual Agent Studio, présenté comme l'alternative sans code au présent dépôt.

Licence MIT et coût de maintenance

Le dépôt est publié sous licence MIT, indiquée à la fois dans le README et dans le fichier LICENSE du dépôt. Concrètement, cela autorise la réutilisation, la modification et la redistribution, y compris dans un produit propriétaire, à condition de conserver l'avis de licence. Cela ne dit rien de la qualité du code ni de la pérennité du projet, et ce texte n'est pas un conseil juridique : pour un usage en entreprise, la vérification des mentions de licence et des dépendances transitives reste à faire. Sur le coût de maintenance, le matériel disponible ne permet pas d'être précis. Aucune version publiée n'a été récupérée, donc impossible de juger le rythme de publication ni la discipline de versionnement. Le dépôt n'est pas archivé et le dernier push est récent, ce qui écarte l'hypothèse d'un projet abandonné, sans prouver autre chose. La vraie question de coût se situe ailleurs : chaque fournisseur que vous utilisez et qui n'est pas dans la liste du README devient un connecteur à écrire et à maintenir vous-même. Le README présente le système de connecteurs comme extensible, ce qui est à la fois la force et la charge du projet.

Conclusion éditoriale

SRE s'adresse aux équipes qui écrivent leurs agents en TypeScript et veulent éviter de recâbler chaque fournisseur LLM, stockage ou cache à la main. Il ne convient pas à qui cherche une orchestration visuelle sans code, ni à qui refuse la dépendance à un vocabulaire et à des abstractions imposés par un seul projet. Avant d'adopter, vérifiez deux choses concrètes : que les connecteurs dont vous dépendez figurent bien dans la liste du README (OpenAI, Anthropic, Google AI, AWS Bedrock, Groq, Perplexity pour les LLM ; Pinecone, Milvus, RAMVec pour les bases vectorielles), et que le paquet @smythos/sdk installé correspond à la version documentée sur smythos.github.io/sre/sdk. Si un fournisseur manque, le système de connecteurs est le point d'extension à examiner en premier.

Sources officielles

1. Issues
2. License: MIT
3. Project website
4. README
5. SmythOS/sre on GitHub