Nous avons rendu ApowerB open source parce que le runtime qui relie modèles, données d’entreprise et outils ne devrait pas être une boîte noire.

Lorsqu’un agent peut utiliser des outils, stocker de la mémoire, accéder à des données métier, s’exécuter de façon planifiée et survivre aux redémarrages, les questions importantes dépassent largement le modèle.

ApowerB est notre réponse à cette couche : un runtime open source pour construire et opérer des agents IA au-delà de la démonstration.

Pourquoi ouvrir le runtime ?

Le modèle vient souvent d’un fournisseur externe. Les données appartiennent à l’entreprise. Les outils appartiennent à l’entreprise. Nous pensons que la couche qui relie ces éléments doit pouvoir être inspectée.

• Inspectabilité : comprendre exécution, état et intégrations.

• Auto-hébergement : déployer sur une infrastructure contrôlée.

• Extensibilité : faire évoluer intégrations et runtime.

• Portabilité : réduire la dépendance à un seul fournisseur.

• Feedback communautaire : confronter les choix à des cas réels.

Le problème que nous voulions résoudre

Les frameworks facilitent prompts, outils et logique agentique. Les difficultés apparaissent ensuite :

• où vit l’état après un restart ?

• comment journaliser les tool calls ?

• peut-on rejouer un run en sécurité ?

• comment gérer credentials et permissions ?

• comment déployer sur Kubernetes ?

• comment comprendre coûts et erreurs ?

Nous avons documenté ces problèmes dans nos articles DEV.to sur le passage à la production, Kubernetes et les incidents de mémoire/replay.

Open source ne doit pas être un argument marketing vide

L’intérêt n’est pas le badge. L’intérêt est qu’un développeur puisse inspecter le système et contester nos choix.

• comment les sessions sont persistées ;

• ce qui se passe lorsqu’un outil a déjà été exécuté ;

• quels composants sont nécessaires au déploiement ;

• comment les providers sont configurés ;

• quelles briques peuvent être remplacées.

Pourquoi le runtime devient central

Un chatbot simple peut rester proche d’un modèle request-response. Un agent qui agit via des outils ne le peut plus.

• cycle de vie d’exécution ;

• état et mémoire ;

• tool execution ;

• orchestration ;

• retries ;

• observabilité ;

• déploiement.

Voir notre guide sur les agents IA prêts pour la production.

Un enseignement de production : persister ne suffit pas

Lors d’un audit, nous avons observé environ huit redémarrages applicatifs par jour. Déplacer les sessions en stockage durable corrigeait l’amnésie, mais pas le replay d’un outil déjà exécuté.

Voir le retour d’expérience DEV.to et notre guide sur la gestion de l’état des agents IA.

Pourquoi l’auto-hébergement compte

Il devient important lorsque l’équipe exige contrôle de la topologie, réseau privé, contraintes de résidence, modification du runtime ou réduction du lock-in.

Voir déployer des agents IA sur Kubernetes.

ApowerB et thaink² sont complémentaires

ApowerB fournit un runtime ouvert aux développeurs. thaink² apporte une plateforme d’entreprise centrée sur la data, l’analytics et la connaissance, ainsi qu’un accompagnement d’ingénierie.

Inspecter le runtime directement

Ce que nous voulons construire en open source

Notre priorité n’est pas d’empiler les abstractions. Elle est de rendre plus clairs les problèmes qui arrivent après le prototype : état durable, tool execution, portabilité des providers, déploiement, observabilité et reprise sûre.