« Clé API Llama » est une recherche fréquente, mais elle ne correspond pas à un produit unifié. Le 6 juillet 2026, la préversion publique de l'API Llama de Meta a été retirée ; pour continuer à utiliser Llama, il faut généralement passer par un fournisseur cloud, une plateforme d'inférence, un déploiement auto-hébergé ou une passerelle compatible OpenAI. Chaque route délivre un identifiant différent : jeton Bearer, identifiant temporaire de compte cloud, ou parfois aucune clé du tout.

Cet article détaille, par route, l'origine de la clé, la réduction des permissions, le stockage en variable d'environnement, le diagnostic des 401 et la rotation après fuite. Les modèles et la facturation font foi sur la page Tarifs des modèles.

Remarque : Meta et Llama sont des marques de Meta Platforms, Inc. ; les autres plateformes et noms de modèles cités sont des marques de leurs détenteurs respectifs. Cet article est purement technique et n'implique aucune affiliation, relation d'agence ou approbation avec Meta ni avec les plateformes mentionnées.

1. Distinguer quatre types de « clé API Llama »

Route Forme de l'identifiant Où le créer Pour qui
Hébergement cloud Rôle IAM, identifiant temporaire ou clé de ressource Console AWS IAM, Microsoft Foundry, Google Cloud Contrat cloud existant, besoin d'audit et de conformité régionale
Plateforme d'inférence Clé API Bearer Console Groq, OpenRouter, etc. Intégration rapide, pas d'exploitation GPU
Inférence auto-hébergée Authentification propre ou réseau interne sans authentification vLLM, Ollama, llama.cpp Frontière de données stricte, GPU disponible
Passerelle compatible Clé API de passerelle Console de la passerelle Entrée unifiée multi-modèles, règlement en yuans

Le même mot ne désigne pas la même chose selon la plateforme. Un identifiant IAM cloud ne se colle pas dans le paramètre api_key du SDK OpenAI ; la clé d'une plateforme d'inférence ne permet généralement pas d'appeler le modèle d'une autre. Confirmez d'abord le type d'identifiant avant de parler d'« obtention ».

2. Route historique : la clé de l'API Llama de Meta appartient au passé

Meta a lancé en 2025 une préversion publique de l'API Llama, avec un point d'entrée hébergé sur api.llama.com et un chemin compatible OpenAI. Cette préversion a été retirée le 6 juillet 2026 ; les anciennes requêtes reçoivent une notification de fin de service ou une redirection, et les anciennes clés ne sont généralement plus valides. Si vous trouvez un tutoriel « créer une clé API Llama dans la console Meta », vérifiez d'abord sa date de publication.

Deux choses doivent être distinguées : les poids du modèle et l'API hébergée. Les poids ouverts de Llama restent fournis sous licence communautaire Llama, téléchargeables depuis la page des modèles de Meta et Hugging Face ; ce qui a été retiré, c'est la couche d'hébergement propriétaire de Meta. La Meta Model API actuellement mise en avant propose la série Muse, et non Llama : ne mélangez pas les deux.

Aujourd'hui, « clé officielle » ne peut donc signifier que deux choses : soit vous téléchargez les poids par le canal officiel et auto-hébergez, en implémentant vous-même l'authentification ; soit vous appelez via un fournisseur cloud ou un hébergeur. Toute page tierce prétendant ouvrir une « clé API Meta Llama officielle » doit être vérifiée.

3. Fournisseurs cloud : des identifiants IAM, pas une clé à coller

AWS Bedrock. Demandez d'abord l'accès au modèle dans la console, puis accordez à l'appelant les permissions minimales bedrock:InvokeModel et bedrock:InvokeModelWithResponseStream. Les appels utilisent la signature SigV4, généralement prise en charge par le SDK ou des identifiants temporaires ; inutile d'inscrire une clé longue durée dans le code. Pour Llama 4 Scout, Bedrock ne prend actuellement en charge que les API Invoke ou Converse, sans point d'entrée Chat Completions ; l'identifiant ressemble à meta.llama4-scout-17b-instruct-v1:0, et l'inférence inter-régions ajoute un préfixe comme us.. La disponibilité varie selon la région et le cycle de vie.

Microsoft Foundry (anciennement Azure AI Foundry). Après déploiement d'un modèle Llama depuis le catalogue, utilisez le point de terminaison de ressource avec une clé, ou l'identité Entra ID. La clé est liée à la ressource ; un changement d'abonnement ou de région impose une nouvelle vérification.

Google Cloud Vertex AI. Appelez via un compte de service ou les identifiants par défaut de l'application, accordez les rôles Vertex AI appropriés et vérifiez projet, région et version du modèle. Surveillez le cycle de vie : Google a annoncé le retrait de llama-3.3-70b-instruct-maas le 21 octobre 2026 ; les équipes qui l'utilisent encore doivent migrer ou passer à un déploiement propre.

Le point commun des routes cloud est une granularité fine des permissions et une chaîne d'audit complète, au prix d'une activation lente et de nombreuses lignes de facturation. Ne diffusez pas la clé à des personnes : rattachez-la à une identité de charge de travail et limitez le réseau source et les régions autorisées.

4. Plateformes d'inférence et passerelles compatibles : la clé Bearer la plus courante

Les plateformes d'inférence comme Groq, OpenRouter et Fireworks, ainsi que les passerelles compatibles OpenAI en Chine, proposent généralement une console où créer un jeton Bearer dans la page API Keys. Les étapes se ressemblent :

  1. Créez un compte et effectuez la vérification e-mail, téléphone ou entreprise demandée.
  2. Ouvrez la page API Keys, créez une clé et nommez-la clairement avec projet, environnement et porteur, par exemple prod-rag-cn.
  3. Choisissez les permissions minimales : uniquement l'inférence, sans gestion de facturation, des membres ou des clés.
  4. Fixez un budget, une limite de débit ou un plafond mensuel pour éviter qu'une clé épuise le compte.
  5. Copiez la clé immédiatement dans un gestionnaire de mots de passe ou un coffre de secrets ; la plupart des plateformes ne l'affichent qu'à la création.
  6. Validez la clé, l'URL de base et le nom du modèle avec une requête minimale, puis seulement écrivez la configuration de production.

La particularité d'une passerelle est qu'une clé peut correspondre à plusieurs modèles amont. Pour ZSQH AI Gateway, l'URL de base est https://ai.zhongshangqihang.com/v1, les modèles disponibles étant ceux de la console et de la page Tarifs des modèles. L'avantage est une facture et des journaux unifiés ; le coût est une couche de transfert supplémentaire. Vérifiez le chemin des données, le traitement des incidents et les règles de facturation.

5. Permissions : une clé ne doit pas être toute-puissante

Traitez la clé comme une identité, pas comme un mot de passe. Utilisez une clé par environnement de production, de test et d'expérimentation personnelle ; aucune clé longue durée dans un front-end, une application mobile ou un dépôt public ; pour un accès direct depuis un navigateur, passez par un jeton de courte durée ou un proxy backend. Activez toutes les restrictions disponibles : liste blanche IP, domaines d'origine, périmètre de modèles, plafond budgétaire.

L'anti-modèle fréquent en équipe est « une clé pour tout le monde ». En cas d'incident, impossible de savoir qui a appelé ; en cas de fuite, impossible de révoquer une seule personne. Séparez les clés par projet, avec étiquettes d'usage et alertes : le diagnostic coûte beaucoup moins cher.

6. Variables d'environnement et code : garder la clé hors de Git

# .env uniquement en local ou dans un coffre de secrets, jamais commité dans Git
export LLAMA_API_KEY="votre_clé"
export LLAMA_BASE_URL="https://api.groq.com/openai/v1"
export LLAMA_MODEL="llama-3.3-70b-versatile"

Les SDK Python, Node et autres lisent souvent OPENAI_API_KEY quand aucun paramètre n'est fourni. Si le même processus appelle aussi d'autres fournisseurs, passez api_key explicitement pour ne pas envoyer la clé de la plateforme A à la plateforme B. Pour les conteneurs et les services systemd, vérifiez que les variables sont réellement injectées, et pas seulement dans le shell courant.

Diagnostic d'un 401, dans l'ordre :

  • l'en-tête est-il Authorization: Bearer <clé>, avec un espace après Bearer ?
  • la clé provient-elle de la plateforme correspondant à l'URL de base ? Une clé inter-plateformes ne fonctionne pas.
  • la clé a-t-elle été révoquée, expirée, ou jamais activée après sa création ?
  • la variable contient-elle des guillemets, un saut de ligne ou un espace introduit au copier-coller ?
  • le processus de service lit-il une ancienne variable, et a-t-il été redémarré après modification ?
  • un 401 signifie que l'identité n'est pas validée ; un 403 signifie le plus souvent que l'identité est validée mais les droits insuffisants. Ne confondez pas les deux.

7. Rotation et révocation : concevoir la sortie dès le départ

  1. Créez une nouvelle clé sur la plateforme, avec la date dans le nom, par exemple prod-2026-10.
  2. Remplacez d'abord dans un service de test ou une instance de préproduction, en surveillant 401, 403 et latence.
  3. Vérifiez qu'aucun échec d'authentification n'apparaît dans les journaux, puis remplacez progressivement les autres environnements.
  4. Gardez un chevauchement entre ancienne et nouvelle clé, sans dépasser un cycle de publication.
  5. Une fois l'ancienne clé sans appel, révoquez-la et vérifiez l'absence d'usage anormal récent.
  6. Mettez à jour le registre des clés : date de création, responsable, usage, prochaine rotation.

Les événements déclencheurs incluent un départ de salarié, une clé apparue dans un journal ou un dépôt, un incident de sécurité chez un fournisseur, et la rotation périodique. En cas de suspicion de fuite, révoquez d'abord, puis enquêtez ; ne commencez pas par modifier le code. Vérifiez aussi la facture et les journaux d'appel pour détecter des modèles ou des régions anormaux.

Questions fréquentes

Peut-on encore demander une clé API Llama à Meta ?

Non. La préversion publique de l'API Llama de Meta a été retirée le 6 juillet 2026 et l'ancien point d'entrée ne fournit plus d'inférence. Les poids Llama restent téléchargeables ; un appel hébergé passe par un fournisseur cloud, une plateforme d'inférence ou une passerelle compatible.

Pourquoi les fournisseurs cloud n'ont-ils pas de clé API à coller ?

Les fournisseurs cloud utilisent généralement des rôles IAM, des comptes de service ou des identifiants temporaires, avec permissions et audit liés au compte cloud. C'est plus fin qu'un jeton Bearer longue durée, mais il faut configurer permissions et signature avant l'intégration, sans réutiliser directement le paramètre api_key du SDK OpenAI.

Une clé permet-elle d'appeler tous les modèles Llama ?

Cela dépend de la plateforme. Une plateforme d'inférence ou une passerelle permet souvent d'appeler plusieurs modèles activés sur le compte avec une seule clé ; un fournisseur cloud applique les permissions IAM, la demande d'accès au modèle et les limites régionales. La disponibilité suit la liste actuelle de la console.

Que se passe-t-il si la clé est placée dans un front-end ou une application ?

Elle est publique. Une capture de trafic suffit à la récupérer et à consommer votre quota. Navigateur et mobile doivent appeler votre backend, qui détient la clé et applique authentification, limites et journaux.

Que vérifier en premier pour un 401 ou un 403 ?

Pour un 401 : la clé elle-même, le format de l'en-tête et la concordance avec l'URL de base. Pour un 403 : les droits de la clé ou du rôle sur le modèle, le projet ou la région visés. Après ces deux vérifications, consultez la page d'état de la passerelle ou du fournisseur cloud.

Pour aller plus loin

Déterminez d'abord la route d'accès, puis créez une clé dédiée : IAM chez un fournisseur cloud, jeton Bearer sur une plateforme d'inférence ou une passerelle, authentification propre en auto-hébergement. Pour une clé, des journaux et une entrée multi-modèles unifiés, commencez par créer un compte sur ZSQH AI Gateway ; les modèles disponibles et la facturation font foi sur la page Tarifs des modèles.

Articles liés :