Airbyte self-hosted : ingestion data open-source — déploiement 2026

Introduction

Imaginez la situation suivante : vous gérez les données de vente d’une PME dakaroise réparties entre un CRM maison sous MySQL, des fichiers CSV exportés depuis Wave, et une base Postgres que votre développeur a bricolée il y a deux ans. Chaque lundi matin, un stagiaire passe deux heures à copier-coller manuellement ces données dans un Google Sheet pour que le directeur commercial puisse y voir clair. Ce scénario n’a rien d’exceptionnel en Afrique de l’Ouest — il est même la norme dans des dizaines de structures qui n’ont pas encore franchi le cap de l’automatisation de la donnée.

Airbyte change radicalement cette équation. Souvent présenté comme le Fivetran open-source, Airbyte est une plateforme d’ingestion de données (ELT) qui permet de connecter plus de 350 sources de données à n’importe quelle destination, de façon automatisée, reproductible et auditable. La différence fondamentale avec les solutions SaaS comme Fivetran ou Stitch réside dans le fait qu’Airbyte peut être déployé entièrement sur votre propre infrastructure — un VPS à 10 000 FCFA par mois suffit pour commencer. Aucune donnée sensible ne quitte votre périmètre, les coûts sont prévisibles, et vous gardez le contrôle total sur les connecteurs.

Ce tutoriel vous accompagne pas à pas depuis l’installation d’Airbyte Community Edition sur un VPS Ubuntu 22.04 jusqu’à la mise en place d’une synchronisation incrémentale avec Change Data Capture (CDC). Vous apprendrez à créer votre premier pipeline de données, à configurer un schedule cron, et à construire un connecteur personnalisé via le Low-Code CDK — le tout en tenant compte des contraintes réelles d’un environnement ouest-africain : bande passante 4G variable, coupures réseau, et besoin d’intégrer des API locales comme Wave ou Orange Money.

Prérequis

Avant de commencer, assurez-vous que votre environnement répond aux exigences minimales. Airbyte Community Edition n’est pas particulièrement gourmand, mais il faut quand même lui allouer des ressources raisonnables pour qu’il tourne de façon stable en production.

• Système d’exploitation : Ubuntu 22.04 LTS (recommandé) ou Debian 12. macOS fonctionne pour le développement local.
• RAM : 4 Go minimum, 8 Go recommandés pour plusieurs connecteurs simultanés.
• CPU : 2 vCPUs minimum. Les workers Airbyte tournent en parallèle, plus de CPU accélère les syncs.
• Stockage : 20 Go minimum. Les logs de sync s’accumulent vite — prévoyez 50 Go si vous gérez plusieurs millions de lignes.
• Docker : version 24.x ou supérieure, avec Docker Compose v2 (plugin intégré, commande docker compose sans tiret).
• PostgreSQL : Airbyte utilise une base Postgres interne pour stocker sa configuration. Elle est incluse dans le déploiement Docker, vous n’avez pas besoin d’en installer une séparément.
• Ports ouverts : 8000 (UI Airbyte) et 8001 (API). Pensez à configurer votre firewall (ufw) en conséquence.
• Temps estimé : 35 à 45 minutes pour une première installation propre avec un connecteur opérationnel.

Si vous partez d’un VPS nu, commencez par mettre à jour le système et installer Docker avant de passer à la suite.

# Mise à jour du système
sudo apt update && sudo apt upgrade -y

# Installation de Docker Engine (méthode officielle)
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh

# Ajouter votre utilisateur au groupe docker pour éviter sudo
sudo usermod -aG docker $USER
newgrp docker

# Vérification
docker --version
docker compose version

Après exécution de ces commandes, docker --version doit afficher quelque chose comme Docker version 26.x.x. Si vous obtenez une erreur de permission, déconnectez-vous et reconnectez-vous à votre session SSH pour que l’ajout au groupe docker prenne effet.

Étape 1 — Comprendre l’architecture d’Airbyte

Avant de lancer la moindre commande d’installation, il est essentiel de comprendre ce qu’Airbyte déploie réellement. Cette connaissance vous sera indispensable pour déboguer les problèmes et optimiser les performances. Airbyte n’est pas un seul binaire monolithique — c’est un ensemble de services qui communiquent entre eux via des files de messages et une base de données centrale.

L’architecture Community Edition se compose de quatre composants principaux. Le airbyte-server est le cerveau de l’application : il expose l’API REST et l’interface web, gère la configuration des connexions, des sources et des destinations, et orchestre les demandes de synchronisation. Le airbyte-worker est le bras exécutif : il reçoit les tâches de synchronisation du serveur et les exécute concrètement, en lançant des conteneurs Docker temporaires pour chaque connecteur source et destination. C’est lui qui consomme le plus de ressources lors des syncs actifs.

Le troisième composant est Temporal, un moteur de workflow open-source que l’équipe Airbyte a choisi pour gérer la durabilité et la résilience des jobs. Si un sync échoue à mi-chemin à cause d’une coupure réseau, Temporal garantit que le travail reprend là où il s’était arrêté — une propriété particulièrement précieuse dans notre contexte ouest-africain. Enfin, airbyte-db est une instance PostgreSQL dédiée qui stocke toute la configuration : les credentials des sources et destinations, l’historique des syncs, les états de curseur pour l’incrémental. Cette base ne doit jamais être partagée avec vos données métier — c’est la base interne d’Airbyte uniquement.

Dans un déploiement Kubernetes (production), deux composants supplémentaires entrent en jeu : airbyte-bootloader (gère les migrations de base au démarrage) et airbyte-pod-sweeper (nettoie les pods éphémères). Mais pour une installation locale ou un VPS unique, le déploiement Docker Compose suffit amplement.

Étape 2 — Déployer via abctl ou Helm

Airbyte propose deux chemins d’installation self-hosted en 2026 : abctl (la CLI officielle, recommandée pour les nouveaux déploiements) et Helm (pour les équipes qui gèrent déjà un cluster Kubernetes). Le choix dépend de votre contexte : si vous débutez ou si vous n’avez pas de cluster K8s, utilisez abctl sur Docker. Si vous avez une infrastructure Kubernetes existante, Helm est le chemin naturel.

Option A — Déploiement avec abctl (recommandé)

abctl est la CLI officielle d’Airbyte, introduite avec la version 0.50 pour simplifier radicalement l’installation. Elle s’occupe de tout : téléchargement des images, configuration réseau, création du namespace, gestion des credentials. Une seule commande remplace l’ancien docker-compose.yml de 300 lignes.

# Télécharger et installer abctl
curl -LsfS https://get.airbyte.com | bash -

# Vérifier l'installation
abctl version

# Lancer l'installation locale d'Airbyte
# Cette commande télécharge toutes les images et démarre les services
abctl local install

# Récupérer les credentials générés automatiquement
abctl local credentials

La commande abctl local install prend entre 5 et 15 minutes selon votre bande passante — elle télécharge plusieurs images Docker (server, worker, temporal, db). Une fois terminée, elle affiche l’URL locale d’accès (par défaut http://localhost:8000) et les credentials initiaux. La commande abctl local credentials vous donne le login et le mot de passe auto-générés. Notez-les précieusement — changez le mot de passe dès votre première connexion.

Option B — Déploiement avec Helm sur Kubernetes

Si vous avez un cluster Kubernetes (K3s sur un VPS, par exemple, ou un cluster managé), Helm reste la méthode de référence pour un déploiement production. Elle offre plus de contrôle sur la configuration et facilite les mises à jour.

# Ajouter le repo Helm officiel Airbyte
helm repo add airbyte https://airbytehq.github.io/helm-charts
helm repo update

# Créer un namespace dédié
kubectl create namespace airbyte

# Installer Airbyte avec les valeurs par défaut
helm install airbyte airbyte/airbyte \
  --namespace airbyte \
  --set global.edition=community

# Vérifier le déploiement
kubectl get pods -n airbyte

Après quelques minutes, kubectl get pods -n airbyte doit afficher tous les pods en état Running. Si un pod reste en Pending, c’est souvent un problème de ressources insuffisantes — vérifiez avec kubectl describe pod -n airbyte pour lire le message d’événement exact. Pour accéder à l’UI, utilisez kubectl port-forward svc/airbyte-airbyte-webapp-svc 8000:80 -n airbyte et ouvrez http://localhost:8000.

Étape 3 — Configurer votre premier connecteur source

Une fois Airbyte opérationnel et accessible via l’UI, l’étape suivante consiste à déclarer une source de données. C’est ici que la richesse d’Airbyte se manifeste : 350+ connecteurs préconfigurés couvrent la quasi-totalité des bases de données relationnelles, des API SaaS, des fichiers plats et des data warehouses. Pour ce tutoriel, nous partons du cas le plus courant en Afrique de l’Ouest : une base de données PostgreSQL existante qui contient des données transactionnelles.

Dans l’interface Airbyte, naviguez vers Sources dans le menu gauche, puis cliquez sur + New source. Dans la barre de recherche, tapez « Postgres » et sélectionnez le connecteur officiel. Le formulaire de configuration demande plusieurs paramètres. Le champ Host attend l’adresse IP ou le nom DNS de votre serveur Postgres. Le Port est 5432 par défaut. Renseignez la Database (le nom de la base à ingérer), le Username et le Password.

Un point important : le compte utilisateur Postgres que vous renseignez doit avoir au minimum les droits SELECT sur les tables à ingérer. Ne jamais utiliser le superutilisateur postgres en production — créez un compte dédié avec des droits minimaux.

-- Créer un utilisateur dédié Airbyte avec droits minimaux
CREATE USER airbyte_reader WITH PASSWORD 'motdepasse_securise';

-- Accorder les droits de lecture sur le schéma cible
GRANT USAGE ON SCHEMA public TO airbyte_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO airbyte_reader;

-- Pour le CDC, accorder également le droit REPLICATION
ALTER USER airbyte_reader REPLICATION;

Une fois les credentials renseignés dans l’UI, cliquez sur Test and save. Airbyte lance un conteneur de test éphémère qui tente de se connecter à votre source et liste les tables disponibles. Si le test réussit, un bandeau vert apparaît et la source est enregistrée. Si vous utilisez MySQL plutôt que Postgres, le processus est identique — sélectionnez le connecteur MySQL et adaptez les paramètres en conséquence. Pour des fichiers CSV hébergés sur un serveur SFTP ou un bucket S3, Airbyte propose respectivement les connecteurs File (SFTP) et Amazon S3, avec la même logique de formulaire.

Étape 4 — Configurer la destination PostgreSQL analytics

La destination est l’endroit où Airbyte va écrire les données après les avoir ingérées depuis la source. Pour une PME qui commence en data engineering, la destination la plus simple et la plus efficace est une seconde base PostgreSQL dédiée à l’analytique — souvent appelée « analytics DB » ou « data warehouse léger ». Cette séparation entre la base de production (source) et la base analytique (destination) est une bonne pratique fondamentale : elle évite que vos requêtes analytiques lourdes n’impactent les performances de l’application métier.

Dans l’UI Airbyte, allez dans Destinations puis + New destination. Sélectionnez le connecteur Postgres (il joue aussi bien le rôle de source que de destination). Renseignez l’hôte, le port, la base et les credentials de votre base analytique. Un paramètre spécifique à la destination mérite votre attention : le Default Schema. Airbyte va créer les tables de destination dans ce schéma — utilisez un nom explicite comme airbyte_raw ou ingestion pour bien identifier les données ingérées.

Airbyte écrit d’abord dans un schéma temporaire (le « raw schema ») avant de finaliser dans le schéma cible. Ce comportement garantit qu’une sync partielle ne laisse pas de données corrompues dans vos tables d’analyse. Cliquez sur Test and save une fois la configuration complète. Si votre base analytique tourne sur le même serveur que la base source, veillez à ce qu’elle soit sur un port ou une base différente — jamais dans la même base de données pour éviter toute confusion.

Étape 5 — Configurer les sync modes : incrémental et CDC

Une fois source et destination configurées, vous créez une Connection (le pipeline reliant les deux). C’est là que se joue la question la plus critique pour l’efficacité de votre ingestion : le sync mode. Airbyte propose trois modes principaux, et le choix entre eux a un impact direct sur la bande passante consommée — un paramètre décisif quand vous travaillez sur une connexion 4G en Afrique de l’Ouest.

Le mode Full Refresh recopie l’intégralité des données à chaque synchronisation. C’est le mode le plus simple mais le plus consommateur : si votre table de commandes contient 500 000 lignes, Airbyte transfère les 500 000 lignes à chaque sync, même si seules 200 commandes ont été créées depuis la dernière exécution. Ce mode est acceptable pour des petites tables (moins de 50 000 lignes) ou pour des tables de référence qui changent peu.

Le mode Incremental — Append est beaucoup plus économique. Airbyte mémorise la valeur maximale d’un « curseur » (typiquement un champ updated_at ou un ID auto-incrémenté) après chaque sync. Au prochain run, il ne récupère que les lignes dont le curseur est supérieur à la valeur mémorisée. Pour une table de 500 000 lignes avec 200 nouvelles commandes par jour, seules ces 200 lignes transitent — une économie de bande passante considérable.

Le mode Incremental — Deduplicated History va plus loin : il gère aussi les mises à jour de lignes existantes, en maintenant une table de destination qui reflète toujours l’état le plus récent de chaque enregistrement, sans doublons. Pour activer ce mode, la table source doit avoir une clé primaire et un champ de curseur.

Enfin, le Change Data Capture (CDC) représente le niveau le plus avancé. Plutôt que d’interroger la source avec une requête SQL, Airbyte lit le journal de transactions (le WAL de PostgreSQL, le binlog de MySQL) pour capturer chaque INSERT, UPDATE et DELETE en temps quasi-réel. Le CDC nécessite une configuration supplémentaire sur la base source (activation de la réplication logique pour Postgres, activation du binlog pour MySQL) mais offre une latence minimale et gère nativement les suppressions.

-- Activer la réplication logique pour Postgres (requis pour CDC)
-- À exécuter dans postgresql.conf ou via ALTER SYSTEM
ALTER SYSTEM SET wal_level = logical;
ALTER SYSTEM SET max_wal_senders = 3;
ALTER SYSTEM SET max_replication_slots = 3;

-- Recharger la configuration (redémarrage requis pour wal_level)
SELECT pg_reload_conf();

-- Créer un slot de réplication dédié à Airbyte
SELECT pg_create_logical_replication_slot('airbyte_slot', 'pgoutput');

-- Créer une publication sur les tables à répliquer
CREATE PUBLICATION airbyte_pub FOR TABLE orders, customers, products;

Après avoir activé la réplication logique, redémarrez PostgreSQL pour que le paramètre wal_level = logical prenne effet. Dans l’UI Airbyte, lors de la configuration de la source Postgres, sélectionnez Logical Replication (CDC) comme méthode de réplication et renseignez le nom du slot (airbyte_slot) et de la publication (airbyte_pub). Le connecteur Airbyte Postgres utilise Debezium sous le capot pour lire le WAL — une librairie éprouvée maintenue par Red Hat.

Étape 6 — Programmer un schedule cron

Un pipeline de données qui tourne manuellement n’a que peu de valeur. L’objectif est que les synchronisations se déclenchent automatiquement selon un calendrier défini. Airbyte propose deux mécanismes de scheduling : une interface graphique avec des préréglages (toutes les heures, toutes les 24 heures, etc.) et une expression cron standard pour les besoins plus précis.

Dans la configuration de votre Connection, repérez la section Schedule. Si vous sélectionnez Scheduled, un menu déroulant propose des fréquences prédéfinies : toutes les heures, toutes les 6 heures, toutes les 24 heures, chaque semaine. Pour un contrôle plus fin, sélectionnez Cron et entrez directement une expression cron. La syntaxe Airbyte suit le standard Quartz Scheduler (6 champs : secondes minutes heures jour-du-mois mois jour-de-semaine).

# Exemples d'expressions cron Airbyte (format Quartz 6 champs)

# Chaque nuit à 2h00 UTC (recommandé pour minimiser l'impact sur la prod)
0 0 2 * * ?

# Toutes les 4 heures
0 0 0/4 * * ?

# Chaque lundi matin à 6h30
0 30 6 ? * MON

# Toutes les heures les jours ouvrables
0 0 * ? * MON-FRI

Pour les PME ouest-africaines avec une connexion internet instable, nous recommandons un schedule nocturne (0 0 2 * * ?) combiné avec le mode incrémental. Les synchronisations nocturnes évitent de saturer la bande passante pendant les heures de bureau, et le mode incrémental garantit que même si une sync échoue, la suivante reprend proprement depuis le dernier point de contrôle. Airbyte conserve également un historique des syncs avec leurs statuts (succès, échec, annulé) accessible dans l’onglet Status de chaque Connection.

Étape 7 — Créer un connecteur personnalisé via le Low-Code CDK

Avec 350+ connecteurs officiels, Airbyte couvre la grande majorité des sources courantes. Mais en Afrique de l’Ouest, vous rencontrerez inévitablement des API propriétaires non couvertes : l’API REST de Wave Sénégal, l’API de paiement CinetPay, les webhooks d’Orange Money, ou une API interne maison. Pour ces cas, Airbyte propose le Low-Code Connector Development Kit (CDK), qui permet de créer un connecteur source sans écrire une seule ligne de Python — uniquement via une déclaration YAML.

Le Low-Code CDK repose sur le concept de manifest : un fichier YAML qui décrit comment votre connecteur doit s’authentifier, quels endpoints appeler, comment paginer les réponses, et quels champs extraire. Airbyte fournit un Connector Builder intégré dans l’UI (menu Builder dans le panneau gauche) qui offre une interface visuelle pour construire ce manifest sans toucher au YAML directement.

# Exemple de manifest Low-Code CDK pour une API REST générique
# (pattern applicable à Wave, CinetPay, ou toute API REST JSON)
version: "0.51.0"
type: DeclarativeSource

check:
  type: CheckStream
  stream_names:
    - transactions

definitions:
  requester:
    type: HttpRequester
    url_base: "https://api.monservice.com/v1/"
    http_method: GET
    authenticator:
      type: BearerAuthenticator
      api_token: "{{ config['api_key'] }}"

  paginator:
    type: DefaultPaginator
    pagination_strategy:
      type: CursorPagination
      cursor_value: "{{ response['next_cursor'] }}"
      stop_condition: "{{ response['next_cursor'] == null }}"

streams:
  - type: DeclarativeStream
    name: transactions
    primary_key: "id"
    retriever:
      type: SimpleRetriever
      requester:
        $ref: "#/definitions/requester"
        path: "transactions"
      paginator:
        $ref: "#/definitions/paginator"
    schema_loader:
      type: InlineSchemaLoader
      schema:
        type: object
        properties:
          id: { type: string }
          amount: { type: number }
          status: { type: string }
          created_at: { type: string, format: date-time }

Ce manifest YAML déclare un connecteur capable de s’authentifier via Bearer Token, de paginer les réponses avec un curseur, et d’extraire les transactions d’une API REST. Dans le Connector Builder d’Airbyte, collez ce YAML dans l’onglet YAML editor, renseignez les paramètres de configuration (URL de base, clé API), et cliquez sur Test pour voir les données réelles renvoyées par votre API. Une fois validé, publiez le connecteur dans votre instance locale — il apparaît immédiatement dans la liste des sources disponibles comme n’importe quel connecteur officiel.

Erreurs fréquentes

Les problèmes ci-dessous reviennent régulièrement lors d’un premier déploiement Airbyte. Ce tableau synthétise les causes et les solutions vérifiées.

Adaptation au contexte ouest-africain

Déployer Airbyte en Afrique de l’Ouest soulève des défis spécifiques que les tutoriels européens ou nord-américains n’abordent jamais. Le premier est la bande passante. Dans de nombreuses structures sénégalaises, ivoiriennes ou maliennes, la connexion internet est une 4G partagée avec un débit effectif qui peut chuter à quelques centaines de kbit/s aux heures de pointe. Un Full Refresh sur une table de 500 000 lignes peut consommer plusieurs gigaoctets de données — un coût significatif et un risque de timeout réel. La solution est systématique : activer le mode Incremental dès que possible. Avec un curseur bien choisi (created_at, updated_at, ou un ID séquentiel), les syncs quotidiens ne transfèrent que le delta — souvent moins de 1 % du volume total.

Le second défi est la fiabilité réseau. Les coupures de courant et les micro-coupures internet sont fréquentes. C’est précisément pour cela qu’Airbyte a intégré Temporal comme moteur de workflow : chaque job de synchronisation est un workflow durable qui reprend automatiquement après une interruption, sans perdre la progression. Pour renforcer cette résilience, configurez un schedule batch nocturne (entre 1h et 4h du matin) quand les réseaux sont généralement moins chargés et les coupures moins fréquentes. Si la sync de la nuit échoue, Airbyte le re-tente automatiquement selon la politique de retry (configurable jusqu’à 5 tentatives).

La troisième particularité est l’intégration des fintech locales. Wave, Orange Money, CinetPay, Flooz — ces plateformes de paiement mobile sont le cœur des transactions en Afrique de l’Ouest, mais elles ne disposent pas de connecteur officiel Airbyte. C’est exactement le cas d’usage du Low-Code CDK décrit à l’étape 7 : créez un connecteur REST générique qui appelle l’API de reporting de votre fintech locale, paginé et authentifié via Bearer Token ou OAuth2. Le manifest YAML prend moins de deux heures à écrire pour une API bien documentée. Une fois le connecteur en place, vos données de transactions Wave arrivent automatiquement dans votre base analytique chaque nuit, prêtes à être exploitées par dbt ou visualisées dans Metabase.

Enfin, pour les structures qui n’ont pas encore de VPS dédié, Airbyte tourne très correctement sur un serveur VPS à 5 000–10 000 FCFA par mois chez des hébergeurs comme Contabo, OVHcloud, ou les offres locales de DataCenter Sénégal. Un VPS 4 Go RAM / 2 vCPUs est suffisant pour gérer 5 à 10 connexions avec des syncs quotidiens. Assurez-vous d’activer les snapshots automatiques de votre VPS — si la base de données interne d’Airbyte est corrompue, un snapshot permet de revenir en arrière en quelques minutes.

Tutoriels frères

• dbt Core : transformer vos données ingérées avec SQL — guide self-hosted 2026 — après l’ingestion avec Airbyte, structurez vos données avec dbt pour les rendre exploitables
• Dagster : orchestrer vos pipelines data self-hosted — déploiement 2026 — orchestrez la séquence Airbyte → dbt → export avec Dagster

Pour aller plus loin

• Retour au pilier : Data engineering self-hosted 2026 : Airbyte, dbt, Dagster, Iceberg
• Documentation officielle : docs.airbyte.com — référence complète, changelog, guides de migration
• GitHub officiel Airbyte : github.com/airbytehq/airbyte — code source, issues, contributions
• Catalogue des connecteurs : docs.airbyte.com/integrations — 350+ connecteurs avec leur statut (GA, Beta, Alpha)
• Prochaine étape recommandée : configurez dbt Core sur la même machine pour transformer les données brutes ingérées par Airbyte en modèles analytiques propres

FAQ

Q : Airbyte Community Edition est-il vraiment gratuit ?
R : Oui, Airbyte Community Edition est 100 % open-source (licence MIT / Elastic License 2.0 selon le composant) et gratuit pour un usage self-hosted. Vous ne payez que l’infrastructure sur laquelle vous le déployez. Airbyte Cloud (le SaaS géré) est payant et facture au volume de données synchronisées. Pour les PME, le self-hosted est presque toujours plus économique dès que le volume dépasse quelques gigaoctets par mois.

Q : Quelle est la différence entre ETL et ELT, et qu’est-ce qu’Airbyte fait exactement ?
R : Dans un pipeline ETL (Extract-Transform-Load), les données sont transformées avant d’être chargées dans la destination. Dans un pipeline ELT (Extract-Load-Transform), les données brutes sont d’abord chargées telles quelles dans la destination, puis transformées. Airbyte fait de l’ELT : il ingère les données brutes (Extract), les charge dans la destination (Load), et laisse un outil comme dbt gérer la transformation (Transform). Cette approche est plus flexible car les données brutes sont toujours disponibles pour des transformations futures.

Q : Peut-on utiliser Airbyte avec Snowflake ou BigQuery comme destination ?
R : Oui, Airbyte propose des connecteurs officiels pour Snowflake, BigQuery, Redshift, Databricks et les principaux data warehouses cloud. Ces connecteurs sont en statut GA (Generally Available) et utilisés en production par des milliers d’équipes. Si votre budget permet un data warehouse cloud, la combinaison Airbyte → Snowflake/BigQuery est très populaire et bien documentée.

Q : Comment gérer les credentials sensibles (mots de passe, clés API) dans Airbyte ?
R : Airbyte stocke tous les credentials chiffrés dans sa base PostgreSQL interne. En self-hosted, le niveau de sécurité dépend de la sécurisation de votre base interne. Pour renforcer la sécurité : (1) placez Airbyte derrière un reverse proxy Nginx avec HTTPS, (2) restreignez l’accès au port 8000 via ufw à votre seule IP, (3) utilisez des comptes de base de données dédiés avec droits minimaux. Ne jamais exposer l’interface Airbyte directement sur internet sans authentification.

Q : Airbyte gère-t-il les suppressions de données en mode CDC ?
R : Oui, c’est l’un des grands avantages du CDC. En mode Full Refresh, si une ligne est supprimée dans la source, elle reste dans la destination (vous ne saurez pas qu’elle a été supprimée). En mode CDC avec Debezium, Airbyte capture les événements DELETE et les propage dans la destination sous forme d’enregistrements marqués comme supprimés (soft delete avec un champ _airbyte_deleted). Cela permet de maintenir une vision fidèle de l’état de la source, y compris les suppressions.

Q : Combien de temps prend la migration d’un pipeline Fivetran existant vers Airbyte ?
R : La migration dépend du nombre de connecteurs à reconfigurer. Pour chaque connecteur Fivetran, il faut trouver l’équivalent Airbyte (souvent identique en termes de fonctionnalités), reconfigurer les credentials, et vérifier la parité des données sur quelques syncs. Comptez entre 30 minutes et 2 heures par connecteur pour une migration soignée. La bonne nouvelle : la plupart des connecteurs Fivetran populaires ont un équivalent Airbyte en statut GA, et les modes de sync (Full Refresh, Incremental) sont conceptuellement identiques.