> ## Documentation Index
> Fetch the complete documentation index at: https://docs.abbyy.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Limitations connues

> Limites et contraintes actuelles dont les clients doivent tenir compte lors de l’utilisation de Vantage 3.0 auto-hébergé.

Quelques contraintes s’appliquent actuellement à Vantage 3.0 auto-hébergé. Tenez-en compte avant de dimensionner ou de planifier un déploiement.

<div id="architectural-constraints">
  ## Contraintes architecturales
</div>

<div id="one-operator-instance-per-cluster">
  ### Une instance de l’opérateur par cluster
</div>

Le chart Helm `vantage-operator` utilise des noms de ressources de portée cluster non paramétrés : le `manager-role` ClusterRole, le `manager-rolebinding` ClusterRoleBinding et le `controller-manager` ServiceAccount. Installer le chart deux fois dans le même cluster (même dans des namespaces différents) entraîne des conflits sur ces ressources. **Installez une seule instance de ce chart par cluster.**

<div id="deployment-support">
  ## Prise en charge du déploiement
</div>

<div id="supported-deployment-targets">
  ### Cibles de déploiement prises en charge
</div>

Vantage 3.0 auto-hébergé prend en charge AKS et Kubernetes autogéré. Les intégrations validées sont documentées dans [Compatibilité](/fr/vantage/self-hosted/v3.0/compatibility). Les autres versions de Kubernetes, maillages de services, contrôleurs d’ingress, moteurs de base de données et remplacements de composants n’ont pas été validés ; rapprochez-vous de votre équipe ABBYY en charge de votre compte avant d’utiliser en production une combinaison ne figurant pas dans la liste.

<div id="database-support">
  ## Prise en charge des bases de données
</div>

<div id="reporting-requires-sql-server">
  ### La génération de rapports nécessite SQL Server
</div>

PostgreSQL est pris en charge pour les services Vantage, mais la charge de travail de génération de rapports utilise des migrations propres à SQL Server et n’est pas disponible avec PostgreSQL. Définissez `vantage.databaseProvider: PostgreSQL` et laissez `vantage.reportingEnabled: false` pour les déploiements avec PostgreSQL.

<div id="mail-delivery">
  ## Envoi d’e-mails
</div>

<div id="smtp-supports-basic-auth-only">
  ### SMTP prend uniquement en charge l’authentification Basic
</div>

SendGrid est le fournisseur de messagerie par défaut : fournissez un secret `sendgridApiKey` et Vantage l’utilisera sans configuration supplémentaire. SMTP n’est utilisé que lorsque vous configurez `spec.smtp`, et le mode SMTP ne prend actuellement en charge que l’authentification Basic ou l’absence d’authentification. Si votre relais de messagerie nécessite un autre mécanisme d’authentification et que vous ne pouvez pas utiliser SendGrid, prévoyez un relais intermédiaire qui redescend vers l’authentification Basic.

<div id="operational-notes">
  ## Notes opérationnelles
</div>

<div id="alternate-ingress-controllers-require-the-vantage-route-contract">
  ### Les contrôleurs d’ingress alternatifs nécessitent le contrat de routage Vantage
</div>

Les configurations d’ingress validées sont la configuration Istio intégrée sur AKS et la configuration Traefik documentée sur Kubernetes autogéré. Tout autre contrôleur d’ingress doit implémenter les mêmes routes, réécritures, comportement TLS, protection du statut interne et schéma HTTPS transmis. La validation d’un autre contrôleur ou d’une autre implémentation de routage relève de votre responsabilité.

Lorsque la terminaison TLS a lieu en amont d’un backend HTTP, les services d’authentification Vantage doivent respecter `X-Forwarded-Proto`. Si les charts de charge de travail n’exposent pas la variable d’environnement requise, utilisez un mécanisme de mutation d’admission pris en charge, comme décrit dans [Kubernetes autogéré](/fr/vantage/self-hosted/v3.0/providers/self-managed#forwarded-https-scheme).

<div id="keda-is-limited-to-217x">
  ### KEDA est limité à la version 2.17.x
</div>

Les charts des charges de travail Vantage actuels utilisent un champ du scaler KEDA qui a été supprimé dans KEDA 2.18. Utilisez KEDA 2.17.3. Avec KEDA 2.18 ou version ultérieure, les ressources `ScaledObject` concernées ne peuvent pas créer leurs HPA et restent dégradées. Voir [Mise à l’échelle automatique avec KEDA](/fr/vantage/self-hosted/v3.0/performance/autoscaling).

<div id="skill-installation-is-not-surfaced-in-argocd">
  ### L’installation des Skills n’apparaît pas dans ArgoCD
</div>

Les Skills sont installés par un job Kubernetes distinct, et non par une application ArgoCD gérée par un opérateur. ArgoCD ne permet donc actuellement pas de suivre la progression de l’installation des Skills. La ressource `Vantage` peut signaler l’état `Ready` alors que le job est toujours en cours d’exécution ; vous pouvez utiliser Vantage pendant l’installation des Skills. Surveillez directement le job avec `kubectl wait`. Voir [Lifecycle](/fr/vantage/self-hosted/v3.0/lifecycle#skill-installation-runs-separately) pour les commandes.

<div id="whats-next">
  ## Étapes suivantes
</div>

<CardGroup cols={2}>
  <Card title="Migrer depuis Vantage 2.7" icon="right-left" href="/fr/vantage/self-hosted/v3.0/migration-from-2.7">
    Planifiez la migration d’un déploiement auto-hébergé 2.7 existant.
  </Card>

  <Card title="Mise à niveau" icon="arrow-up" href="/fr/vantage/self-hosted/v3.0/upgrading">
    Procédure manuelle de mise à niveau pour passer d’une version 3.0 à une autre.
  </Card>
</CardGroup>