ApowerB intègre désormais Eden AI comme fournisseur de modèles à part entière. Concrètement, un agent construit avec ApowerB peut accéder, avec une seule clé Eden AI, à plusieurs fournisseurs et modèles derrière une API unifiée tout en conservant la possibilité d’utiliser l’endpoint européen d’Eden AI lorsque la résidence des données en Europe est requise.

Cette intégration est née d’un objectif simple : éviter qu’une architecture agentique soit inutilement couplée à un seul fournisseur de modèles. Les agents doivent pouvoir évoluer, changer de modèle, appliquer des règles de routage et rester exploitables dans des environnements où les contraintes de sécurité, de coût, de disponibilité et de localisation des données comptent autant que la qualité brute du modèle.

Techniquement, l’intégration a été réalisée dans ApowerB, le moteur agentique open source développé par thaink². Eden AI y apparaît désormais comme un provider dédié dans la couche modèle. Côté utilisateur, l’endpoint est préconfiguré : il suffit de renseigner une clé API Eden AI et de sélectionner un modèle compatible.

Pourquoi intégrer Eden AI dans ApowerB ?

Un agent IA en production ne devrait pas dépendre d’un modèle comme une application classique dépend d’une fonction locale. Les modèles évoluent vite, leurs prix changent, leurs performances varient selon les tâches et leur disponibilité n’est jamais parfaitement uniforme.

Dans ce contexte, une AI gateway joue un rôle différent de celui du runtime agentique.

• ApowerB exécute les agents, leurs outils, leur état, leurs sessions, leurs workflows et leurs règles de production.

• Eden AI fournit une couche d’accès unifiée à de nombreux modèles et fournisseurs, avec des mécanismes de routing, de fallback, de contrôle des coûts et de sélection régionale.

Les deux couches sont donc complémentaires. Le runtime décide quoi faire ; la gateway aide à décider quel modèle ou fournisseur utiliser pour le faire.

Une intégration pensée pour éviter le verrouillage fournisseur

L’un des principaux intérêts d’Eden AI est de proposer une interface commune au-dessus de plusieurs fournisseurs de modèles. D’après sa documentation actuelle, Eden AI se positionne comme une AI gateway et un LLM router donnant accès à environ 1 000 modèles et modèles spécialisés via une même API, avec plus de 50 fournisseurs disponibles selon les capacités et les régions.

Pour ApowerB, cela signifie qu’un agent peut utiliser un modèle Eden AI sans que le code de l’agent ait besoin d’être réécrit pour chaque fournisseur sous-jacent.

Le modèle est référencé avec un préfixe edenai/ qui conserve ensuite l’identifiant du fournisseur et du modèle sélectionnés.

{
  "agent_model": "edenai/anthropic/claude-haiku-5-5",
  "agent_model_params": {
    "model_api_key": "<eden-ai-api-key>"
  }
}

{
  "agent_model": "edenai/anthropic/claude-haiku-5-5",
  "agent_model_params": {
    "model_api_key": "<eden-ai-api-key>"
  }
}

L’endpoint standard Eden AI est utilisé par défaut. ApowerB permet également de définir un model_api_base spécifique lorsque l’entreprise souhaite utiliser un endpoint régional.

Le catalogue n’est volontairement pas figé dans ApowerB : il est récupéré depuis l’API Eden AI. Cela évite de maintenir manuellement une liste de modèles qui devient obsolète dès qu’un fournisseur ajoute, remplace ou retire un modèle.

Le vrai enjeu : le routing des modèles

L’intégration ne sert pas uniquement à « avoir plus de modèles dans une liste ».

L’intérêt d’une gateway apparaît lorsque l’on commence à raisonner en règles de production :

• préférer un fournisseur pour son coût ;

• utiliser un autre fournisseur lorsque la latence devient prioritaire ;

• restreindre les modèles autorisés par organisation ou environnement ;

• déclarer des fallbacks en cas d’indisponibilité ;

• conserver une conversation sur un même fournisseur lorsque cela est pertinent ;

• imposer une région de traitement lorsque la conformité l’exige.

Eden AI documente aujourd’hui des stratégies de routing par coût, vitesse ou latence, des listes de fournisseurs autorisés et des mécanismes de fallback. La gateway peut ainsi devenir une couche de gouvernance entre l’agent et les modèles qu’il consomme.

Pourquoi l’angle européen et la souveraineté comptent

La collaboration entre Eden AI et thaink² a aussi un intérêt particulier dans le contexte européen.

Eden AI est une entreprise française basée à Lyon. thaink² est née à Metz et développe ApowerB comme moteur agentique open source. Cette proximité ne suffit évidemment pas, à elle seule, à rendre une architecture « souveraine ». La souveraineté dépend du lieu de traitement, du fournisseur réellement utilisé, du contrôle de l’infrastructure, des données et des dépendances techniques.

Mais Eden AI apporte une brique particulièrement concrète : un endpoint européen dédié.

L’endpoint https://api.eu.edenai.run/v3 est conçu pour maintenir le traitement des requêtes dans l’Union européenne. Eden AI indique que les prompts, fichiers, requêtes et sorties y sont traités et routés au sein de l’UE, avec une politique de Zero Data Retention par défaut pour les appels synchrones. Les modèles qui ne peuvent pas respecter la contrainte régionale peuvent être refusés plutôt que routés hors de la région demandée.

Pour un déploiement ApowerB qui souhaite utiliser ce chemin européen, la configuration peut simplement pointer vers cet endpoint :

{
  "agent_model": "edenai/mistral/mistral-small-latest",
  "agent_model_params": {
    "model_api_key": "<eden-ai-api-key>",
    "model_api_base": "https://api.eu.edenai.run/v3"
  }
}

{
  "agent_model": "edenai/mistral/mistral-small-latest",
  "agent_model_params": {
    "model_api_key": "<eden-ai-api-key>",
    "model_api_base": "https://api.eu.edenai.run/v3"
  }
}

La bonne lecture n’est donc pas « tout modèle accessible via Eden AI est souverain ». Elle est plus précise : l’intégration permet de combiner un runtime agentique open source auto-hébergeable avec une gateway européenne capable d’appliquer des contraintes de région et de fournisseur.

Une seule clé Eden AI, plusieurs modèles derrière l’agent

Dans ApowerB, l’objectif est de réduire la friction côté utilisateur.

Eden AI apparaît désormais dans le sélecteur de modèles comme un fournisseur à part entière. L’utilisateur renseigne sa clé Eden AI, puis sélectionne le modèle qu’il souhaite utiliser parmi ceux exposés par le catalogue.

Cette approche est particulièrement utile dans trois scénarios.

1. Tester plusieurs modèles sans reconstruire l’agent

Un agent de RAG peut être évalué avec plusieurs modèles ; un agent analytique peut être testé sur une autre famille ; un workflow de génération peut évoluer sans modifier la logique des outils et des sessions.

2. Préparer un fallback fournisseur

Une architecture de production ne devrait pas supposer qu’un fournisseur sera toujours disponible. Une gateway facilite la mise en place d’un chemin alternatif sans déplacer toute la responsabilité de fallback dans le code de chaque agent.

3. Centraliser la gouvernance des modèles

Une organisation peut vouloir limiter les modèles utilisables, suivre les coûts ou contraindre certaines équipes à une région donnée. Eden AI centralise ces contrôles au niveau de la gateway ; ApowerB garde les contrôles liés aux agents, aux utilisateurs, aux outils et aux workflows.

ApowerB reste open source et auto-hébergeable

Cette intégration ne transforme pas ApowerB en dépendance à Eden AI.

ApowerB supporte déjà plusieurs fournisseurs via sa couche modèle et peut continuer à être utilisé directement avec OpenAI, Anthropic, Mistral, Gemini, Azure AI Foundry, OVHcloud ou d’autres backends compatibles.

Eden AI devient un chemin supplémentaire : celui d’une gateway multi-provider. L’utilisateur peut donc choisir entre :

• une clé fournisseur directe ;

• une infrastructure de modèle auto-hébergée ;

• une AI gateway comme Eden AI ;

• plusieurs stratégies selon les agents ou environnements.

C’est une propriété importante pour nous : le runtime agentique doit rester indépendant du choix de modèle.

Le code et la documentation d’ApowerB sont accessibles sur GitHub, et la documentation technique est disponible sur docs.apowerb.com.

Eden AI et thaink² : deux couches, un même objectif de contrôle

thaink² construit une plateforme où des agents spécialisés peuvent rechercher, analyser, prévoir et agir à partir des données d’entreprise. ApowerB fournit la couche open source qui exécute ces agents et orchestre leurs outils.

L’intégration Eden AI renforce une autre dimension : la liberté de choisir le modèle et le fournisseur sans figer l’architecture agentique.

La combinaison devient particulièrement intéressante pour les entreprises qui veulent concilier :

• agents et workflows auto-hébergeables ;

• accès multi-modèles ;

• routing fournisseur ;

• contrôle régional ;

• fallbacks ;

• suivi des coûts et de l’usage ;

• possibilité de changer de backend plus tard.

Une intégration construite avec Eden AI

Cette intégration est aussi le résultat d’un travail direct entre les équipes thaink² et Eden AI.

Nous remercions l’équipe Eden AI pour les échanges autour de l’intégration et Dave côté thaink² pour la mise en œuvre technique et la validation du chemin complet dans ApowerB.

La collaboration ne s’arrête pas à une mention dans un catalogue : Eden AI documentera également ApowerB dans ses ressources d’intégration, afin que les développeurs puissent connecter les deux couches depuis l’un ou l’autre environnement.

Construire un agent sans figer son fournisseur de modèle

Découvrez ApowerB, le runtime agentique open source de thaink², et configurez Eden AI comme gateway multi-modèles avec une seule clé.

Comment connecter Eden AI à ApowerB

Pour les développeurs, le chemin est volontairement court :

1. obtenir une clé API Eden AI depuis Eden AI ;

2. ouvrir la configuration du modèle dans ApowerB ;

3. sélectionner Eden AI comme provider ;

4. renseigner la clé API ;

5. sélectionner l’identifiant du modèle souhaité ;

6. si nécessaire, définir https://api.eu.edenai.run/v3 comme base URL pour le chemin européen.

L’intégration et les exemples de configuration sont disponibles dans le README ApowerB. Eden AI publiera de son côté une page d’intégration dédiée avec un guide de connexion.

Ce que cette intégration change concrètement

Pour un développeur, elle réduit la quantité de code spécifique à chaque provider. Pour une équipe plateforme, elle ouvre un point de contrôle supplémentaire sur les modèles utilisés. Pour une organisation européenne, elle permet d’introduire une contrainte de région sans remplacer le runtime agentique.

Mais la décision importante reste architecturale : ne pas confondre le modèle, la gateway et l’agent.

Le modèle génère. Eden AI route et gouverne l’accès à des modèles. ApowerB exécute les agents et leurs workflows. thaink² construit les expériences et services d’entreprise au-dessus de cette infrastructure.

En séparant ces responsabilités, il devient beaucoup plus simple de faire évoluer chaque couche sans reconstruire les autres.