OVHcloud AI Endpoints

Des modèles ouverts (gpt-oss, Llama, Mistral, Qwen) hébergés en France par OVHcloud. La clé se crée dans l’espace client OVHcloud, rubrique AI Endpoints.

Connectez une clé d’API OVHcloud AI Endpoints pour que les nœuds IA travaillent avec des modèles ouverts (gpt-oss, Llama, Mistral, Qwen), hébergés en France par OVHcloud. La connexion est réglée une fois pour toute l’organisation par un administrateur ; les membres l’emploient ensuite depuis l’éditeur de workflow sans jamais voir la clé.

Les requêtes partent vers l’API compatible OpenAI d’AI Endpoints, à l’adresse https://oai.endpoints.kepler.ai.cloud.ovh.net/v1. L’adresse est fixe et ne se modifie pas.

En bref

• Identifiant : ovhcloud
• Famille : Fournisseur d’IA
• Configurée par : Un administrateur, pour toute l’organisation
• Authentification : Clé d’API du fournisseur
• Type de credential : llm_provider

Avant de commencer

• Un compte OVHcloud doté d’un projet Public Cloud, dans lequel se créent les clés d’API d’AI Endpoints.
• Un compte administrateur sur Loop & Roll : seuls les administrateurs gèrent les connexions d’IA.
• Une instance dotée d’une clé de chiffrement (ENCRYPTION_KEY), indispensable pour stocker un secret.

Qui la configure

Les connexions d’IA appartiennent à l’organisation, pas à un membre. Seul un administrateur peut les créer, les modifier, les tester ou les supprimer, depuis la page Connexions. Un membre voit la section Intelligence artificielle avec la mention « Les fournisseurs d’IA sont configurés une fois pour toute l’organisation, par un administrateur. » Il ne voit jamais de clé : dans l’éditeur de workflow, il choisit seulement une connexion par son libellé, et un modèle.

La clé est chiffrée avant d’être enregistrée et n’est plus jamais réaffichée : l’écran n’en montre que les quatre derniers caractères (« Clé enregistrée (se termine par …) »). Enregistrer une clé exige la clé de chiffrement de l’instance (ENCRYPTION_KEY, voir Variables d’environnement) ; sans elle, l’enregistrement échoue avec llm.encryption_disabled.

Créer une clé d’API chez OVHcloud

1. Connectez-vous à l’espace client OVHcloud, ouvrez votre projet Public Cloud, puis AI Endpoints › API keys. Dans Loop & Roll, le lien Où trouver cette clé ? de la carte OVHcloud AI Endpoints ouvre le guide de démarrage d’OVHcloud, qui détaille la création du projet et de la clé : https://help.ovhcloud.com/csm/en-public-cloud-ai-endpoints-getting-started?id=kb_article_view&sysparm_article=KB0065401.
2. Créez une nouvelle clé. Nommez-la d’après votre instance pour la reconnaître plus tard.
3. Copiez la clé tout de suite et gardez-la jusqu’à la coller dans Loop & Roll : elle n’est plus réaffichée en entier.

La clé est obligatoire. AI Endpoints répond bien sans clé, mais à 2 requêtes par minute et par adresse IP seulement, contre 400 par minute avec une clé : un workflow de production ne tiendrait pas sous la limite anonyme.

Ajouter la connexion

1. Ouvrez Connexions dans la navigation principale.
2. Dans la section Intelligence artificielle, repérez la ligne OVHcloud AI Endpoints et cliquez sur Configurer. (Vous pouvez aussi cliquer sur Ajouter dans cette section et choisir OVHcloud AI Endpoints dans le catalogue.)
3. Libellé : pré-rempli avec le nom du fournisseur. Changez-le si vous comptez détenir plusieurs clés (« Prod », « Client X »).
4. Clé d’API : collez la clé. Elle est obligatoire pour une nouvelle connexion et n’est jamais réaffichée.
5. (Aucune URL de serveur à saisir : les requêtes partent toujours vers l’adresse officielle du fournisseur, qui ne se modifie pas.)
6. Modèles activés : voir la section sur les modèles activés ci-dessous.
7. Cliquez sur Enregistrer, puis sur Tester.

Tester et Voir les modèles disponibles ne sont proposés qu’une fois la connexion enregistrée. Quand vous modifiez une connexion enregistrée, laissez le champ Clé d’API vide pour conserver la clé ; n’en collez une que pour la remplacer.

Choisir les modèles activés

OVHcloud AI Endpoints dispose d’un catalogue intégré dans Loop & Roll. La carte liste chaque modèle avec son tarif par million de tokens (entrée et sortie) :

Modèle	Entrée	Sortie	Remarque
gpt-oss-20b	0,05 $	0,18 $	Recommandé pour classer, extraire et l’analyse de boîte
gpt-oss-120b	0,09 $	0,47 $	Recommandé pour rédiger, l’usage général et l’assistant de workflows
Meta-Llama-3_3-70B-Instruct	0,74 $	0,74 $	Inutilisable par l’assistant de workflows (voir Tools et assistant de workflows)
Mistral-Small-3.2-24B-Instruct-2506	0,10 $	0,31 $

• Avec tous les modèles cochés (l’état initial), il n’y a aucune restriction : un nœud peut aussi nommer un modèle d’AI Endpoints absent de cette liste.
• Décochez des modèles pour restreindre la connexion : un nœud qui nomme un modèle décoché échoue alors avec llm.model_not_allowed. Il faut garder au moins un modèle (« Activez au moins un modèle — sinon supprimez le fournisseur. »).

Le catalogue ne contient que les quatre modèles mesurés avec Loop & Roll. AI Endpoints en sert d’autres (Qwen 3.x, Mistral Nemo…) : pour les employer, cliquez sur Voir les modèles disponibles. La carte affiche « n modèles rendus par le fournisseur. » et les ajoute à la liste, avec le tarif par million de tokens et la longueur de contexte que publie OVHcloud ; les modèles d’embedding, de synthèse vocale et d’image sont écartés, car les nœuds IA ne savent pas les employer. Cochez les modèles que vos workflows peuvent employer, puis cliquez sur Enregistrer. Dès lors, les modèles cochés forment la liste d’autorisation de cette connexion : un nœud qui nomme un autre modèle échoue avec llm.model_not_allowed. Les modèles restés cochés restent listés même si une liste ultérieure ne les rend plus : un trou passager chez le fournisseur ne les décoche jamais en silence.

Les modèles gpt-oss raisonnent avant de répondre. Loop & Roll en tient compte : pour une réponse structurée, il demande un effort de raisonnement faible et ajoute une marge de tokens de sortie pour le raisonnement.

Tester la connexion

Tester envoie une vraie requête minimale (« ping », 5 tokens de sortie au plus) avec la clé de la connexion affichée dans la carte. Il prouve que la clé peut compléter, pas seulement qu’elle est acceptée. Le test emploie gpt-oss-20b s’il est activé, sinon le premier modèle activé. En cas de succès, la carte affiche « Connexion établie avec modèle en n ms. » ; sinon « Le test a échoué : » suivi de la raison (voir Erreurs fréquentes).

Voir les modèles disponibles est une autre vérification : OVHcloud publie sa liste de modèles en accès public, si bien qu’une liste obtenue prouve que le service répond, pas que votre clé est valide. Seul Tester vérifie la clé. La liste est gardée dix minutes, par connexion ; enregistrer ou supprimer une connexion du fournisseur l’efface.

Quel fournisseur et quel modèle un nœud IA utilise

Les nœuds IA (par exemple Catégoriser, Extraire, Rédiger (IA), Résumer et Instruction libre (IA)) appellent chacun le modèle avec un usage : classer, extraire, rédiger ou usage général. L’analyse de boîte a son propre usage. Pour chaque appel, le fournisseur et le modèle se résolvent dans cet ordre — la première règle applicable l’emporte :

1. Un nœud fournisseur câblé sur le port model du nœud — par exemple un nœud OVHcloud AI Endpoints. Ses champs Connexion et Modèle s’appliquent ; un Modèle vide signifie « le modèle recommandé pour cet usage chez ce fournisseur ».
2. Le choix de l’administrateur pour cet usage, dans le panneau Quelle IA pour quel usage de la page Connexions.
3. Le défaut de l’instance — la première ligne de ce panneau, « Par défaut (tous les usages non réglés) ». Elle peut nommer un fournisseur seul (« … · modèle recommandé ») ou un fournisseur et un modèle.
4. Le premier fournisseur configuré, par date de configuration (sans préférence de marque), avec le modèle recommandé pour l’usage.

Un choix devenu inutilisable (clé retirée, modèle décoché) est ignoré au profit de la règle suivante, et le panneau affiche « Choix inapplicable » à côté. Sous chaque ligne, « Utilise : fournisseur · modèle » montre ce que le prochain appel obtiendra réellement. Quand rien ne peut servir un usage, la ligne affiche « Aucun » et les nœuds échouent avec llm.no_provider_configured ou llm.no_default_model.

Quand OVHcloud AI Endpoints est le fournisseur retenu et qu’aucun modèle n’est nommé, les modèles recommandés sont gpt-oss-20b pour classer, extraire et l’analyse de boîte, et gpt-oss-120b pour rédiger, l’usage général et l’assistant de workflows. Les badges « Défaut : … » de la carte OVHcloud AI Endpoints montrent quels usages OVHcloud sert en ce moment.

Plusieurs clés pour un même fournisseur

Une organisation peut détenir plusieurs connexions OVHcloud AI Endpoints — par exemple une clé de production et une clé refacturée à un client. Chaque connexion a son Libellé, sa clé et sa liste de modèles activés.

• Pour en ajouter une, ouvrez la carte du fournisseur et cliquez sur Ajouter une connexion. Le libellé est obligatoire et doit être unique (sinon : « Ce libellé est déjà utilisé par une autre connexion. »).
• La première connexion d’un fournisseur devient automatiquement sa connexion Par défaut. À partir de deux, la carte les liste ; cliquez sur Mettre par défaut sur une autre pour déplacer le défaut.
• La connexion par défaut est celle qu’emploie tout ce qui n’en nomme aucune : les défauts par usage, le défaut de l’instance, l’analyse de boîte, et tout nœud fournisseur dont le champ Connexion reste sur « Par défaut (…) ».
• Pour imposer une clé précise à un nœud, choisissez-la dans le champ Connexion du nœud fournisseur OVHcloud AI Endpoints.

Pour supprimer une connexion, sélectionnez-la, cliquez sur Supprimer, puis sur Confirmer la suppression. Deux refus protègent les workflows en service :

• si des workflows publiés référencent la connexion, la carte affiche « Des workflows publiés utilisent cette connexion ; confirmez pour la supprimer quand même. » et les nomme. Confirmer une nouvelle fois la supprime, et ces nœuds échoueront alors avec llm.connection_not_found jusqu’à ce que vous choisissiez une autre connexion ;
• la connexion par défaut ne se supprime pas tant que le fournisseur en a d’autres (llm.connection_is_default) : mettez-en d’abord une autre par défaut. Supprimer la dernière connexion retire le fournisseur de l’instance.

Utiliser OVHcloud AI Endpoints dans un workflow

Pour qu’un nœud IA travaille avec OVHcloud AI Endpoints quels que soient les défauts de l’instance, câblez-lui un nœud fournisseur :

1. Ajoutez le nœud OVHcloud AI Endpoints sur le canevas (fiche du nœud).
2. Tirez un lien de ce nœud vers le port model du nœud IA.
3. Dans Connexion, gardez « Par défaut (…) » pour employer la connexion par défaut du fournisseur, ou choisissez une autre connexion par son libellé.
4. Dans Modèle, laissez le champ vide pour employer le modèle recommandé pour l’usage du nœud, ou saisissez un identifiant de modèle. L’éditeur propose les modèles activés sur la connexion choisie et prévient quand l’identifiant n’y est pas activé (« Ce modèle n’est pas activé sur la connexion choisie : l’exécution le refusera. »).
5. Température est facultative ; laissez-la vide pour garder le réglage du fournisseur.

Le nœud fournisseur n’est pas une étape : il ne s’exécute jamais seul, ne porte aucune clé, et indique seulement au nœud IA câblé quel fournisseur, quelle connexion et quel modèle employer. Un même nœud fournisseur peut alimenter plusieurs nœuds IA.

Si la connexion choisie a été supprimée, l’exécution échoue avec llm.connection_not_found — elle ne se rabat jamais sur une autre clé. Si la connexion appartient à un autre fournisseur, l’exécution échoue avec llm.connection_provider_mismatch.

Sortie structurée

Quand un nœud attend une réponse structurée, Loop & Roll envoie le schéma JSON attendu sous forme de format de réponse json_schema, qu’AI Endpoints impose par une grammaire pendant que le modèle écrit. Certains schémas sont refusés par cette grammaire (HTTP 400, par exemple « Grammar error ») : Loop & Roll retente alors une fois en mode JSON simple, avec le schéma attendu ajouté aux consignes système. Si la réponse reste illisible, Loop & Roll tente une réparation ; au-delà, l’étape échoue avec llm.invalid_json.

Tools et assistant de workflows

L’assistant de workflows a besoin d’un modèle qui sait appeler des tools. Tous les modèles d’AI Endpoints ne le font pas de façon fiable :

• gpt-oss-120b (recommandé) et Mistral-Small-3.2-24B-Instruct-2506 fonctionnent avec l’assistant. gpt-oss-120b ne fait qu’un appel de tool par tour, même quand deux sont attendus : l’assistant enchaîne alors les tours, ce qui coûte un aller-retour de plus, pas un résultat faux.
• Meta-Llama-3_3-70B-Instruct écrit ses appels de tools sous forme de texte au lieu de les faire : l’assistant le refuse avant le premier appel (« Ce modèle ne sait pas utiliser d’outils. Choisissez-en un autre sous le champ de message. »). Il en va de même de tout modèle Llama coché après Voir les modèles disponibles.

Cela ne concerne que l’assistant : les nœuds IA n’appellent pas de tools, et Meta-Llama-3_3-70B-Instruct reste utilisable pour eux.

Pendant un essai

Un essai appelle le vrai modèle : vous voyez la catégorie, l’extraction ou le brouillon que le modèle produit réellement. Seules les actions irréversibles (envoi, déplacement, requêtes HTTP) sont simulées. Un appel d’essai coûte autant qu’en production et apparaît dans Usage et coûts de l’IA.

La sortie n’est fabriquée que si l’instance n’a aucun fournisseur utilisable — aucune connexion d’IA, ou un nœud fournisseur câblé vers un fournisseur non configuré. L’éditeur affiche alors « IA sautée : aucune clé sur cette instance », et l’effet de l’étape indique qu’aucun modèle n’aurait été appelé faute de fournisseur d’IA configuré. Quand un modèle peut être résolu, l’effet nomme le modèle que l’exécution emploierait réellement. La sortie fabriquée est la plus petite valeur conforme à la forme attendue : la première catégorie à vrai, les champs texte à simulated.

Les refus de politique ne sont pas masqués pendant un essai : un modèle non activé (llm.model_not_allowed), une connexion supprimée (llm.connection_not_found), un quota épuisé ou une panne du fournisseur font échouer l’essai exactement comme en production.

Coûts et données

Les appels sur les modèles du catalogue sont valorisés avec le tableau ci-dessus et affichés dans Usage et coûts de l’IA sur la page Connexions (administrateurs seulement), ventilés par origine : workflows, mise au point de prompt et analyse de boîte. Un modèle coché depuis Voir les modèles disponibles est compté en appels et en tokens, sans coût : les tarifs affichés dans la liste aident à choisir, ils ne servent pas à calculer les coûts.

Le raisonnement des modèles gpt-oss est compté dans les tokens de sortie, et facturé comme tel. Le coût est donc juste, mais OVHcloud ne précise pas combien de ces tokens sont partis en raisonnement : le détail des tokens d’une étape n’affiche jamais la mention « dont … de raisonnement » pour ces modèles.

Le contenu des e-mails traités par un nœud IA est envoyé à OVHcloud, qui héberge AI Endpoints en France.

Erreurs fréquentes

Les erreurs sont signalées par un code stable, que l’interface traduit. Sur la page Connexions, la raison d’un Tester ou d’une liste de modèles en échec s’affiche dans la carte du fournisseur, et les autres refus (enregistrement, suppression) dans un bandeau en haut de la section ; pendant une exécution, le code figure dans l’erreur de l’étape. Voir aussi Gestion des erreurs et rejeu et la référence des codes d’erreur.

Code	Cause	Que faire
llm.invalid_api_key	Le fournisseur a refusé la clé (HTTP 401 ou 403) : révoquée, mal copiée ou sans accès.	Créez une nouvelle clé chez le fournisseur, collez-la dans la carte, Enregistrer, puis Tester. L’exécution n’est pas retentée.
llm.rate_limited	Le fournisseur a répondu 429, 502, 503, 504 ou 529 (quota, crédits ou surcharge), ou la limite propre à l’instance (LLM_MAX_REQUESTS_PER_MINUTE, 60 appels par minute et par fournisseur par défaut) est atteinte. AI Endpoints autorise 400 requêtes par minute et par clé.	Rien à faire pour un pic passager : l’étape est différée puis reprise sans consommer de tentative, à l’heure qu’indique l’en-tête RateLimit-Reset de la réponse d’OVHcloud. Si cela dure, vérifiez votre quota chez le fournisseur.
llm.timeout	Le fournisseur n’a pas répondu dans le délai LLM_REQUEST_TIMEOUT_MS (120 secondes par défaut).	Retenté automatiquement. Pour de longues rédactions sur un serveur lent, relevez le délai.
llm.provider_unavailable	Erreur réseau, ou autre réponse 5xx du fournisseur.	Retenté automatiquement avec un délai croissant. Vérifiez l’état du fournisseur si cela dure.
llm.provider_rejected	Le fournisseur a refusé la requête elle-même (HTTP 400, 404 ou 422) : identifiant de modèle inconnu, entrée trop longue, schéma refusé.	Vérifiez l’identifiant du modèle dans le nœud fournisseur ou les modèles activés. L’exécution n’est pas retentée.
llm.model_not_allowed	Le modèle nommé par le nœud n’est pas activé sur la connexion employée.	Cochez le modèle dans la carte, ou nommez un modèle activé dans le nœud fournisseur.
llm.no_default_model	Aucun modèle ne peut être choisi pour cet usage : pas de modèle recommandé chez ce fournisseur et aucun modèle activé. Également renvoyé par Tester quand il n’y a aucun modèle avec lequel tester.	Activez au moins un modèle sur la connexion, ou nommez le modèle dans le nœud fournisseur.
llm.no_provider_configured	Aucune connexion d’IA n’existe sur l’instance.	Un administrateur ajoute une connexion sur la page Connexions.
llm.provider_not_configured	Un nœud fournisseur est câblé vers un fournisseur sans connexion, ou le premier enregistrement est parti sans clé.	Configurez le fournisseur, ou câblez un nœud fournisseur d’un fournisseur configuré.
llm.connection_not_found	La connexion choisie dans le nœud fournisseur a été supprimée.	Choisissez une autre connexion dans le champ Connexion du nœud, puis republiez.
llm.connection_provider_mismatch	La connexion choisie dans le nœud appartient à un autre fournisseur que le nœud.	Choisissez une connexion du bon fournisseur, ou remplacez le nœud fournisseur.
llm.invalid_json	Le modèle a rendu un JSON inexploitable pour une sortie structurée, même après la nouvelle tentative en JSON simple et une réparation automatique.	Relancez, ou employez un modèle plus capable pour ce nœud.
llm.output_truncated	La réponse structurée a été coupée par le plafond de tokens de sortie.	Demandez moins, ou relevez LLM_DEFAULT_MAX_OUTPUT_TOKENS (4 096 par défaut).
llm.empty_output	Un modèle à raisonnement a consacré tout son budget au raisonnement et n’a rien écrit.	Relancez, ou employez un autre modèle pour ce nœud.
llm.content_refused	Le modèle a refusé de répondre à ce contenu.	Revoyez la consigne ou l’entrée. L’exécution n’est pas retentée.
llm.connection_in_use	Suppression refusée : des workflows publiés utilisent la connexion (leurs noms sont listés).	Changez d’abord leur connexion, ou confirmez la suppression une seconde fois.
llm.connection_is_default	Suppression refusée : c’est la connexion par défaut du fournisseur et d’autres existent.	Cliquez sur Mettre par défaut sur une autre connexion, puis supprimez celle-ci.
llm.connection_label_taken	Une autre connexion utilise déjà ce libellé.	Choisissez un autre libellé.
llm.encryption_disabled	L’instance n’a pas de ENCRYPTION_KEY : elle ne peut stocker aucun secret.	Définissez la variable et redémarrez l’instance.
llm.discovery_failed	La liste des modèles n’a pas pu être lue : réponse inattendue du fournisseur.	Vérifiez l’état du fournisseur, puis relancez Voir les modèles disponibles.

Nœuds qui utilisent cette connexion

• OVHcloud AI Endpoints — llm.ovhcloud