Auto-hébergement

Ce guide s’adresse à l’équipe IT / exploitation qui va installer et faire tourner Abra sur l’infrastructure du client — cloud privé, datacenter ou serveur on-premise. Vous y trouverez tout le cycle de vie : de la préparation du serveur au premier démarrage, puis la configuration, les sauvegardes, les mises à jour et la supervision au quotidien.

Abra se livre comme une stack conteneurisée (Docker Compose) que vous hébergez entièrement chez vous. Vos données métier, vos clés de modèles et vos connecteurs restent sur votre infrastructure : aucune donnée métier ne transite par les serveurs d’Abra. Le déploiement d’une instance neuve prend de l’ordre de 15 à 20 minutes avec l’installateur guidé fourni.

---

Vue d’ensemble : SaaS ou auto-hébergé ?

Abra existe sous deux formes qui partagent exactement le même produit ; seule change la personne qui exploite l’infrastructure.

En SaaS, Abra héberge et opère la plateforme pour vous : vous ouvrez un espace, vous invitez vos équipes, et vous n’avez ni serveur, ni mise à jour, ni sauvegarde à gérer. C’est le chemin le plus rapide et le plus léger côté IT.

En auto-hébergé (le sujet de cette page), c’est vous qui exploitez la stack sur vos propres serveurs. Vous récupérez une image applicative dédiée à votre organisation et vous la faites tourner derrière votre réseau. Ce mode est fait pour les organisations qui ont des exigences fortes de souveraineté et de résidence des données :

• Les données ne quittent pas votre périmètre. Base, fichiers, historiques de conversation, connaissances (RAG) : tout vit sur votre infrastructure.
• Vous gardez la main sur les flux sortants. Vous décidez quels fournisseurs de modèles sont joignables, ou vous branchez vos propres modèles internes.
• Conformité et audit. Vous appliquez vos propres politiques de rétention, de chiffrement au repos, de journalisation et de contrôle d’accès réseau.
• Isolation réseau possible jusqu’au mode air-gap (sans Internet sortant), sur demande.

SaaS ou auto-hébergé : le produit est identique, seule change la frontière d’exploitation. En auto-hébergé, tout ce qui touche à vos données reste dans votre périmètre.

Comment choisir ? Si votre priorité est la vitesse de mise en route et le zéro-ops, partez sur le SaaS. Si vous avez une contrainte réglementaire, un RSSI qui exige la localisation des données, ou une politique « on-premise par défaut », partez sur l’auto-hébergement décrit ci-dessous.

---

Prérequis

Serveur

Un serveur Linux (VM ou bare-metal), dimensionné selon votre nombre d’utilisateurs. Toute la stack tient sur une seule machine — vous n’avez pas besoin d’orchestrateur pour démarrer.

Profil	Utilisateurs	VM	Stockage
Petit / POC	< 500	4 vCPU / 16 GB	200 GB SSD
Standard (recommandé)	500 – 5 000	8 vCPU / 32 GB	200 GB SSD
Croissance	5 000 – 10 000	16 vCPU / 64 GB	400 GB SSD
Grand compte	> 10 000	32 vCPU / 128 GB	800 GB SSD

Ces paliers dépendent de votre profil d’usage (chat IA intensif vs consultation de tableaux de bord). Pour un dimensionnement précis, container par container, avec les capacités mesurées, votre interlocuteur Abra vous remet une note de sizing adaptée à votre cas. En cas de doute, partez sur le profil Standard : vous pourrez monter en gamme plus tard sans migration de données (snapshot disque → nouvelle VM plus grosse → bascule DNS, ~10 min).

Prévoyez du SSD (la base est le facteur limitant) et gardez au moins 30 % d’espace disque libre en régime permanent, pour les sauvegardes locales, les logs et le téléchargement des nouvelles images lors des mises à jour.

Logiciels

• Linux moderne : Ubuntu 24.04 LTS recommandé (Debian 12, RHEL 9 conviennent également).
• Docker Engine ≥ 26.0 avec le plugin Docker Compose v2.
• Utilitaires standards : openssl, curl, tar.

Installation de Docker en une commande :

curl -fsSL https://get.docker.com | sudo sh && sudo usermod -aG docker $USER
# Se reconnecter (logout/login SSH) pour activer le groupe docker

Un domaine + TLS

Abra s’expose sur des sous-domaines de votre domaine. Créez 3 enregistrements A pointant vers l’IP publique de votre serveur (un pour l’application, deux pour le moteur d’automatisation interne) :

abra.votre-domaine.com          A   <ip-serveur>   # interface Abra (utilisateurs)
moteur.votre-domaine.com           A   <ip-serveur>   # moteur de workflows (admins)
moteur-dev.votre-domaine.com       A   <ip-serveur>   # workflows en brouillon

N’utilisez que des tirets dans les hostnames, jamais d’underscore : moteur_prod n’est pas un nom d’hôte HTTP valide et casse les certificats TLS.

Le TLS se termine sur le reverse-proxy inclus dans la stack — vous n’avez rien à installer en plus. Deux options courantes :

• Certificat d’origine Cloudflare (recommandé si vous êtes derrière Cloudflare : valide 15 ans, aucun renouvellement à gérer).
• Let’s Encrypt ou votre PKI interne : fournissez simplement votre .crt et votre .key, ils sont montés dans le proxy.

Si vous placez Abra derrière votre propre reverse-proxy d’entreprise (F5, NGINX central, Traefik…), c’est possible : terminez le TLS chez vous et transmettez le trafic au proxy de la stack. Signalez-le à votre interlocuteur Abra pour recevoir la variante de configuration adaptée.

Connectivité sortante

Ports entrants à ouvrir depuis Internet (via votre pare-feu / CDN) :

80   HTTP    → redirige automatiquement vers 443
443  HTTPS   → interface Abra + moteur de workflows

Le serveur doit pouvoir sortir en HTTPS (443) vers :

• Le registre d’images — pour récupérer votre image au démarrage et lors des mises à jour.
• Le service de licence Abra — une connexion sortante périodique suffit à maintenir votre instance activée (voir la section Licence).
• Les fournisseurs de modèles que vous activez (OpenAI, Anthropic, Mistral, Google, ou votre passerelle interne). Vous n’activez que ceux dont vous avez besoin.

Environnement air-gap (sans Internet sortant) : c’est possible sur demande, avec une licence en mode hors-ligne et un transfert d’image manuel. Vous restez alors maître de vos propres modèles internes. Contactez votre interlocuteur Abra pour le kit hors-ligne.

---

Ce que vous recevez

Votre interlocuteur Abra vous transmet, via un canal sécurisé (par exemple un lien à expiration courte), un petit kit de déploiement :

Élément	Description
Bundle de déploiement (deploy-<slug>.tar.gz, quelques dizaines de Ko)	Le fichier docker-compose de production, un .env d’exemple, l’installateur install.sh, un smoke-test.sh et la configuration du reverse-proxy.
Fichier de licence	Le jeton qui autorise votre instance (nombre d’utilisateurs, d’organisations, date de validité). À coller pendant l’installation.
Identifiants du registre	Un nom d’utilisateur + un jeton d’accès en lecture seule pour récupérer votre image.

L’image applicative est construite spécifiquement pour votre organisation et publiée sous un tag qui vous est dédié (…:<votre-slug>-stable). Vous n’avez ni le code source à gérer, ni rien à compiler : vous récupérez l’image prête à l’emploi et vous la démarrez.

Ces trois éléments (bundle, licence, identifiants de registre) sont sensibles : traitez-les comme des secrets. Ne les commitez jamais dans un dépôt Git et ne les partagez pas par email en clair.

Le bundle de déploiement, une fois extrait : tout ce qu’il faut pour lancer l’instance tient dans un dossier de quelques fichiers.

---

Installation guidée

Sur votre serveur Linux fraîchement provisionné, l’installation se fait en trois temps : extraire le bundle, poser les certificats, lancer l’installateur.

# 1. Récupérer et extraire le bundle
mkdir -p ~/abra && cd ~/abra
tar xzf deploy-<slug>.tar.gz
cd deploy

# 2. Placer vos certificats TLS
mkdir -p reverse-proxy/certs
cp <votre-cert>.crt reverse-proxy/certs/origin.crt
cp <votre-cert>.key reverse-proxy/certs/origin.key
chmod 600 reverse-proxy/certs/origin.key

# 3. Lancer l'installateur guidé
bash install.sh

Ce que l’installateur vous demande

install.sh ne vous pose que les informations qu’il ne peut pas deviner :

? Domaine principal Abra          (ex : abra.votre-domaine.com)
? Domaine moteur PROD                (ex : moteur.votre-domaine.com)
? Domaine moteur DEV                 (ex : moteur-dev.votre-domaine.com)
? Email de l'admin initial        (ex : admin@votre-domaine.com)
? Mot de passe de l'admin initial (saisie masquée)
? Nom de l'organisation           (ex : ACME Corp)
? Fichier de licence              (chemin ou collez le contenu reçu)
? Identifiant + jeton du registre (saisie masquée)

L’installateur guidé ne demande que l’essentiel : domaines, compte admin, licence et accès au registre. Tout le reste est généré automatiquement.

Ce que l’installateur fait pour vous

Une fois les réponses saisies, le script enchaîne tout seul :

1. Vérifie l’environnement (Docker ≥ 26.0 et Compose v2 présents).
2. Génère l’ensemble des secrets internes (chiffrement des connecteurs, sessions, mots de passe des bases) — vous n’avez aucun secret à inventer.
3. Écrit le fichier .env (permissions 600) et la configuration du reverse-proxy à partir de vos réponses.
4. Se connecte au registre et récupère les images (compter quelques Go, 8 à 10 min selon votre lien).
5. Démarre la stack avec le fichier de production (docker compose -f docker-compose.production.yml up -d).
6. Attend que l’application soit healthy : le tout premier démarrage applique la migration initiale de la base (2 à 3 min).
7. Affiche les URLs et un récapitulatif de l’installation.

Premier démarrage : l’app s’amorce toute seule

Au tout premier lancement, Abra initialise lui-même votre organisation, votre compte administrateur (l’email et le mot de passe saisis) et les rôles/équipes par défaut. Vous n’avez aucune commande de bootstrap à taper à la main : dès que les conteneurs sont healthy, l’instance est utilisable.

Vérification post-installation

bash smoke-test.sh

Le smoke-test vérifie que tous les conteneurs sont healthy, que l’API de santé répond, que la base et le moteur de workflows sont joignables, que la licence est validée et que l’accès HTTPS public fonctionne. Ouvrez ensuite https://abra.votre-domaine.com et connectez-vous avec l’email et le mot de passe admin saisis pendant l’installation.

Première connexion : l’écran de login est servi en HTTPS sur votre domaine, et le compte admin initial est déjà créé.

Sauvegardez le .env dès maintenant. C’est votre fichier de configuration et le coffre des secrets qui protègent vos données. Sans lui, une restauration ne pourra pas relire vos données chiffrées. Voir la section Sauvegardes & restauration.

---

Configurer l’instance

L’instance tourne, mais elle est encore « nue ». Depuis l’interface d’administration, réglez les points suivants. Rien de tout cela n’est requis au moment de l’installation — vous pouvez le faire à froid.

• Changez le mot de passe admin au premier login.
• SMTP — renseignez votre serveur d’envoi d’e-mails (invitations, notifications, réinitialisations de mot de passe). Sans SMTP, les invitations par e-mail ne partent pas.
• SSO — branchez votre fournisseur d’identité (Microsoft Entra ID, Google Workspace…) pour que vos collaborateurs se connectent avec leurs comptes d’entreprise.
• Clés des fournisseurs de modèles — saisissez vos clés OpenAI / Anthropic / Mistral / Google, ou utilisez une clé plateforme mutualisée si votre opérateur en fournit une.
• Modèles autorisés (allowlist) — choisissez la liste des modèles réellement proposés à vos utilisateurs, et posez éventuellement des budgets.
• Connecteurs — connectez vos outils métier (Microsoft 365, Google Workspace, bases de données, API internes…) pour que les agents puissent agir dessus.

Paramètres → Fournisseurs IA : vos clés de modèles (ou la clé plateforme) et la liste des modèles autorisés pour vos utilisateurs.

Le détail complet de ces réglages — rôles, membres, équipes, gouvernance des modèles, budgets, marque — est couvert dans le Guide de l’administrateur. Cette page-ci se concentre sur l’exploitation de l’infrastructure.

---

Sauvegardes & restauration

La base de données (agents, workflows, membres, connaissances, historiques) est votre donnée critique — planifiez des sauvegardes dès le jour 1. Deux choses sont à protéger :

1. La base de données — la totalité de votre contenu.
2. Le fichier .env — les secrets de chiffrement qu’il contient sont indispensables pour relire vos données après une restauration. Une sauvegarde de base sans le .env correspondant est inexploitable.

Pensez aussi aux volumes de fichiers (documents importés pour le RAG, pièces jointes) si votre installation en utilise : ils se sauvegardent au même rythme que la base.

Sauvegarde quotidienne minimale

cd ~/abra/deploy
docker compose -f docker-compose.production.yml exec abra-db \
  pg_dump -U postgres abra | gzip > backup-abra-$(date +%F).sql.gz

Copiez ces sauvegardes hors du serveur (stockage objet chiffré, autre fournisseur, autre site). Une sauvegarde qui vit sur la même machine que la base ne protège de rien en cas de perte du serveur.

Fréquence recommandée

• Base + volumes : quotidien au minimum ; plusieurs fois par jour pour un usage intensif.
• Fichier .env : à chaque changement (il bouge rarement), conservé dans votre coffre à secrets d’entreprise.
• Rétention : appliquez votre politique (par exemple 7 quotidiennes, 4 hebdomadaires, 12 mensuelles).

Restaurer

Sur un serveur remis à neuf, réinstallez la stack avec le même .env (celui d’origine, pas un .env régénéré), puis réimportez le dump :

cd ~/abra/deploy
gunzip -c backup-abra-2026-08-13.sql.gz | \
  docker compose -f docker-compose.production.yml exec -T abra-db \
  psql -U postgres abra

Testez une restauration réelle chaque trimestre. Une sauvegarde jamais restaurée n’est pas une sauvegarde. Votre interlocuteur Abra peut vous fournir une procédure détaillée (règle 3-2-1, chiffrement, objectifs RPO/RTO) adaptée à vos contraintes.

---

Mises à jour

Les mises à jour se font par remplacement d’image (« image-swap ») : on récupère la nouvelle version et on relance le conteneur applicatif, sans toucher à votre configuration ni à vos données. Votre tag <slug>-stable pointe toujours vers la dernière version publiée pour vous.

cd ~/abra/deploy
docker compose -f docker-compose.production.yml pull
docker compose -f docker-compose.production.yml up -d --force-recreate abra

Durée : ~5 min. Une éventuelle migration de base s’applique automatiquement au démarrage. Aucune modification du .env n’est nécessaire, sauf mention explicite dans les notes de version.

Trois règles d’or pour une mise à jour sereine :

1. Préservez le .env. Ne le régénérez jamais lors d’une mise à jour — il contient vos secrets de chiffrement. Une mise à jour ne fait que changer l’image.
2. Ne touchez jamais à la base à la main. Les migrations sont gérées par l’application au démarrage. N’exécutez pas de SQL manuel de schéma.
3. Sauvegardez avant. Faites un dump juste avant chaque montée de version.

Revenir à une version précédente

Chaque version est aussi publiée sous un tag immuable (<slug>-vX.Y.Z). Pour revenir en arrière, pointez le .env sur cette version et relancez :

# Dans .env :  ABRA_TAG=<slug>-v0.0.5
docker compose -f docker-compose.production.yml up -d --force-recreate abra

Comme la base peut avoir migré vers un schéma plus récent, un retour en arrière de plusieurs versions se fait de préférence avec le support Abra — d’où l’importance de la sauvegarde d’avant-mise-à-jour.

---

Licence

Votre instance fonctionne grâce au fichier de licence remis par Abra. Cette licence définit simplement ce à quoi votre contrat vous donne droit :

• le nombre maximum d’utilisateurs ;
• le nombre maximum d’organisations ;
• la date de validité ;
• votre niveau de contrat.

Vous suivez l’état de votre licence directement dans l’interface d’administration : plafonds, usage courant, date d’expiration et statut de connexion. Vous n’avez rien à manipuler techniquement au-delà du collage de la clé à l’installation et au renouvellement.

L’écran d’état de licence : d’un coup d’œil, vos plafonds, votre consommation et la date d’échéance.

Connectivité requise

Pour rester active, l’instance a besoin d’une connexion sortante périodique vers le service de licence Abra (la sortie HTTPS mentionnée dans les Prérequis). Concrètement, du côté de votre exploitation, retenez ceci :

• Laissez le port 443 sortant ouvert vers le service de licence.
• Seules des données techniques de licence circulent (validité, version, disponibilité, volume d’usage agrégé pour anticiper les renouvellements). Aucune donnée métier n’est transmise.
• Une coupure réseau brève est sans conséquence : l’instance continue de fonctionner et se resynchronise dès que la connexion revient.
• Besoin d’un fonctionnement totalement déconnecté ? Le mode air-gap (licence hors-ligne, sans connexion sortante) est disponible sur demande.

Renouvellement

À l’approche de l’échéance (en général J-30), Abra vous remet une nouvelle licence. Le renouvellement est un simple remplacement de valeur, sans réinstallation :

cd ~/abra/deploy
# Remplacez la ligne de licence dans le fichier .env par la nouvelle valeur, puis :
docker compose -f docker-compose.production.yml up -d --force-recreate abra

Un changement de plafond (plus d’utilisateurs, plus d’organisations) suit exactement le même chemin : nouvelle licence, même commande. Aucune coupure de service, aucune perte de données.

---

Supervision

Une fois en production, la stack est conçue pour tourner sans intervention. Voici où regarder pour vérifier qu’elle va bien.

Santé des conteneurs

Tous les services publient un healthcheck. L’état healthy est votre premier indicateur :

cd ~/abra/deploy
docker compose -f docker-compose.production.yml ps

Chaque service doit être Up et healthy. Un conteneur qui redémarre en boucle (Restarting) signale un problème à investiguer dans les logs.

Tous les conteneurs Up (healthy) : l’état nominal d’une instance en bonne santé.

Logs

# Logs applicatifs en direct
docker compose -f docker-compose.production.yml logs -f abra

# Les 200 dernières lignes d'un service donné (ex : base)
docker compose -f docker-compose.production.yml logs --tail=200 abra-db

Les logs applicatifs sont structurés : vous pouvez les brancher sur votre collecteur d’entreprise (ELK, Loki, Datadog…) via le pilote de logs Docker de votre choix.

Points à surveiller

• Espace disque — la base et les logs grossissent ; alertez à 80 %.
• Empreinte mémoire / CPU — si vous approchez durablement la capacité de la VM, il est temps de monter de gamme (voir le tableau de Prérequis).
• Santé applicative — l’endpoint de santé HTTP est idéal pour votre supervision externe (UptimeRobot, sonde interne, load-balancer).
• Statut de licence — visible dans l’admin ; une alerte apparaît avant l’échéance.

Les logs applicatifs, structurés, se branchent directement sur votre stack d’observabilité existante.

---

Questions fréquentes

Puis-je couper complètement Internet sur le serveur ? Oui, mais pas en configuration standard. Le mode par défaut a besoin d’une sortie HTTPS périodique pour la licence et pour joindre les fournisseurs de modèles cloud. Si vous devez fonctionner totalement déconnecté, demandez le mode air-gap (licence hors-ligne + image transférée manuellement) et prévoyez d’utiliser vos modèles internes. Une coupure réseau courte ne pose aucun problème : l’instance continue et se resynchronise au retour.

Comment je mets à jour Abra ? Par remplacement d’image : docker compose ... pull puis up -d --force-recreate abra. Cela dure ~5 min, ne touche ni au .env ni à la base, et les migrations éventuelles s’appliquent seules au démarrage. Sauvegardez juste avant, par principe. Voir la section Mises à jour.

Où sont stockées mes données ? Uniquement sur votre serveur. La base et les volumes de fichiers vivent dans des volumes Docker sur votre machine. Aucune donnée métier ne part chez Abra — seules des informations techniques de licence transitent en sortie. C’est tout l’intérêt de l’auto-hébergement.

Que dois-je sauvegarder, et à quelle fréquence ? La base de données et les volumes de fichiers (quotidien au minimum), ainsi que le fichier .env (à chaque changement, dans votre coffre à secrets). Le .env est indispensable : sans lui, une base restaurée reste illisible. Copiez toujours les sauvegardes hors du serveur et testez une restauration chaque trimestre.

Puis-je ajouter un serveur pour encaisser plus de charge ? La stack est prévue pour saturer d’abord une seule machine : dans la très grande majorité des cas, monter la VM en gamme (plus de vCPU/RAM) suffit et se fait sans migration de données (snapshot → VM plus grosse → bascule DNS). Une répartition multi-serveurs avec un vrai load-balancer est possible pour les très gros volumes — c’est une architecture à cadrer avec l’équipe Abra, pas un simple docker run de plus.

J’ai perdu mon fichier .env. Que se passe-t-il ? Le .env contient les secrets de chiffrement de vos données. Sauvegardez-le absolument : sans lui, il n’est pas possible de relire les données chiffrées après une restauration. Conservez-en une copie dans votre coffre à secrets d’entreprise dès l’installation.

Puis-je héberger Abra derrière mon propre reverse-proxy d’entreprise ? Oui. Vous pouvez terminer le TLS sur votre proxy central (F5, NGINX, Traefik…) et transmettre le trafic à la stack. Signalez-le à votre interlocuteur Abra pour recevoir la variante de configuration adaptée.

Combien de temps pour déployer une instance neuve ? De l’ordre de 15 à 20 minutes avec l’installateur guidé, dont l’essentiel est le téléchargement de l’image et la première migration de base.

---

Besoin d’aide ? Pour l’exploitation, appuyez-vous sur le smoke-test.sh, la supervision ci-dessus et votre interlocuteur Abra. Pour l’administration au quotidien (membres, rôles, gouvernance des modèles, marque), rendez-vous dans le Guide de l’administrateur.