Data Engineering ETI — La fondation data de tous vos projets IA
Sans pipeline data fiable, pas d'IA en production. Nehos construit les architectures data (dbt, Airbyte, Delta Lake, Medallion Architecture) pour alimenter vos agents IA et LLMs. Audit data d'abord, pipelines ensuite. Prix de départ : audit approfondi 2 125 € HT, MVP d'agent IA 11 000 € HT.
Nos clients types
#Pourquoi le data engineering est la vraie fondation de tout projet IA en 2026
Une situation classique en audit de cadrage. Le CDO d'une ETI industrielle arrive convaincu que son projet IA est prêt à démarrer — le LLM est sélectionné, le budget validé, l'équipe constituée. En phase de découverte, on lui demande combien de systèmes contiennent des données clients.
La réponse arrive par couches successives : le CRM Salesforce, bien sûr. L'ERP SAP aussi. Mais aussi un Oracle Forms legacy que personne n'ose migrer. Des fichiers Excel partagés sur un serveur réseau — dont un que seule une assistante de direction sait lire. Et les données d'une filiale rachetée, encore sur leur propre SQL Server. Plusieurs systèmes, plusieurs formats de date incompatibles, aucun identifiant client commun entre les sources.
Ce n'est pas un cas exceptionnel. C'est fréquent dans les ETI françaises.
Beaucoup de projets IA échouent à cause de la donnée, pas à cause du modèle. Le modèle LLM est rarement le problème — Mistral Large 2, Claude Sonnet, GPT-4o, tous sont capables de raisonner sur des données propres. Le problème, c'est d'alimenter ces modèles avec une donnée unifiée, qualifiée, cohérente et conforme RGPD. C'est précisément le travail du data engineering.
Nous avons fait un choix structurant : tous nos projets IA démarrent par un audit data. Aucun LLM, aucun agent IA, aucun pipeline RAG souverain ne se déploie sur de la donnée non auditée. Ce n'est pas une contrainte — c'est la condition pour que le projet ne s'arrête pas sur un problème de qualité des données.
#Les 5 problèmes data les plus fréquents en ETI
#1. La fragmentation des sources
ERP, CRM, bases legacy Oracle ou SQL Server, fichiers Excel, données de filiales rachetées — une ETI opère souvent de nombreuses sources de données métier hétérogènes. Chaque source a son propre format, ses propres conventions de nommage, sa propre logique de clés.
#2. L'absence d'identifiant unique cross-systèmes
Le même client existe sous trois formes dans trois systèmes : « Groupe Moreau SA » dans SAP, « MOREAU » dans Salesforce, et « GRP MOREAU » dans le fichier Excel de la direction commerciale. Aucune clé commune. L'agent IA qui interroge la donnée ne sait pas que c'est le même client — il renvoie trois réponses divergentes.
#3. Les données legacy non documentées
Des systèmes Oracle Forms des années 2000 fonctionnent encore dans de nombreuses ETI industrielles. Leurs schémas ne sont pas documentés. Les colonnes portent des noms cryptiques (COL_MAST_22, DTEFF, CLNT_STAT3). La personne qui les connaît a souvent quitté l'entreprise. Reverse engineering du schéma avant toute ingestion — c'est systématique chez nous.
#4. La qualité de données dégradée
Champs vides, doublons clients non dédupliqués, dates saisies manuellement dans des formats différents selon les équipes, codes produits désynchronisés entre l'ERP et le catalogue CRM. Sans une couche de validation continue (Great Expectations sur chaque pipeline), l'agent IA ingère de la mauvaise donnée et produit de mauvaises réponses — avec une confiance apparente que les utilisateurs prennent au sérieux.
#5. L'absence de gouvernance data
« Qui est propriétaire de cette donnée ? » La question laisse souvent les DSI perplexes. Sans data catalog (Apache Atlas ou DataHub), sans data lineage (OpenLineage), sans propriétaires de domaines identifiés, la donnée devient incontrôlable à mesure que l'entreprise grandit. Et quand le projet IA arrive, on découvre que personne ne sait d'où vient la donnée d'entraînement.
#Notre approche : data mesh vs data lake vs lakehouse — le choix selon la maturité
Il n'y a pas d'architecture universelle. Le bon choix dépend de la maturité data de l'ETI, du nombre de domaines métier impliqués et du délai cible pour le premier agent IA en production.
Data lake classique — stockage objet non structuré (OVHcloud Object Storage), ingestion brute, traitement ad hoc. Pertinent pour les ETI qui centralisent leurs données pour la toute première fois. Simple à initier, gouvernance minimale. Problème : vite ingérable sans couche de transformation et de qualité. On ne recommande plus le data lake pur en 2026, sauf comme étape transitoire avant la migration vers un lakehouse.
Lakehouse (Delta Lake / Apache Iceberg + Medallion Architecture) — notre recommandation pour la plupart des projets ETI. Combine la flexibilité du lake (formats ouverts, pas de schéma imposé à l'ingestion) et les garanties ACID d'un warehouse (transactions, time travel, compaction automatique).
La Medallion Architecture organise la donnée en trois couches : bronze (donnée brute ingérée), silver (données nettoyées et normalisées), gold (agrégats métier exploitables par les agents IA et LLMs).
Data mesh — architecture distribuée où chaque domaine métier est propriétaire de ses données et les expose comme des produits data. Pertinent pour les grandes ETI avec des domaines métier autonomes (finance, supply chain, RH, commercial) qui n'ont pas intérêt à centraliser tout dans un même lake. Plus long à mettre en place, mais scalable. On l'implémente en mode progressif — un domaine pilote, puis déploiement par vagues.
Le choix se fait à l'audit, avec le DSI et le CDO, sur la base de la cartographie des sources et de la maturité des équipes internes.
#Stack technique : dbt, Airbyte, Apache Spark, Delta Lake, OVHcloud Object Storage
La stack data engineering type en 2026 est open source et hébergeable en France :
- Airbyte — orchestration de l'ingestion depuis toutes les sources. Connecteurs natifs SAP, Salesforce, HubSpot, Oracle, SQL Server, PostgreSQL, MySQL. Mode CDC (Change Data Capture) pour l'ingestion en quasi-temps réel sans charge sur les systèmes source. Nombreux connecteurs disponibles, développement d'un connecteur sur mesure si nécessaire.
- dbt Core — transformation et modélisation de la donnée en SQL déclaratif. Versioning Git, tests de qualité intégrés, documentation auto-générée des modèles. Le choix de dbt plutôt que Spark pour les transformations SQL classiques : plus maintenable par les équipes data internes, pas de surcharge infrastructure pour les volumétries ETI standard.
- Apache Spark 3.5 — pour les transformations à haute volumétrie et les pipelines ML feature engineering. Déployé sur OVHcloud Managed Kubernetes quand la volumétrie le justifie (gros volumes traités par batch).
- Delta Lake — format de table open source sur OVHcloud Object Storage. ACID transactions, time travel (retour en arrière sur n'importe quelle version), compaction automatique des petits fichiers. Compatible Apache Iceberg si l'ETI préfère un format encore plus ouvert et multi-cloud.
- OVHcloud Object Storage — stockage objet français compatible S3, avec un hébergement qualifié SecNumCloud possible pour les données sensibles.
- Great Expectations — validation de la qualité data à chaque étape du pipeline. Suites de tests sur les couches silver et gold : null checks, format checks, référentiels de valeurs autorisées. Alertes automatiques si la qualité data descend sous un seuil.
- Apache Atlas + OpenLineage — gouvernance et data lineage. Qui a produit cette donnée gold ? À partir de quelle source ? Quelle transformation ? Traçabilité complète, indispensable pour les audits RGPD et les projets en secteur régulé.
→ Pour aller plus loin : découvrez nos outils gratuits — calculateurs ROI, diagnostics techniques et quiz interactifs pour affiner votre réflexion.
#Intégrations sources : ERP, CRM, bases legacy
L'ingestion depuis les systèmes source est toujours le premier chantier — et souvent le plus complexe. Les intégrations habituelles :
ERP : SAP S/4HANA via SAP Cloud Integration ou connecteur JDBC direct. Sage X3 et Sage 100 via API REST ou extraction fichier planifiée. Cegid via API. Pour les ERP legacy sans API (Oracle Forms, AS/400), extraction par lecture directe de la base de données sous-jacente — Oracle Database, IBM DB2 — avec un audit préalable du schéma.
CRM : Salesforce via Airbyte connector natif (lecture bulk API 2.0). HubSpot via API native. Zoho CRM, Pipedrive, Microsoft Dynamics 365 — connecteurs Airbyte disponibles ou développement custom selon la version.
→ Pour aller plus loin : découvrez nos outils gratuits — calculateurs ROI, diagnostics techniques et quiz interactifs pour affiner votre réflexion.
Bases legacy : Oracle Database (y compris des versions anciennes), SQL Server 2008+, PostgreSQL, MySQL. Mode CDC via Debezium (capture du transaction log) pour les bases actives — zéro impact sur les performances du système source. Pour les bases en fin de vie, extraction one-shot + migration vers Delta Lake avec conservation du schéma historique.
Autres sources : fichiers Excel/CSV sur SharePoint ou réseau partagé (ingestion automatisée via script Python + Airbyte custom source), APIs REST tierces (météo, données financières, données sectorielles), flux streaming Kafka si l'ETI dispose déjà de cette infrastructure.
La modernisation SI legacy Nehos peut accompagner en parallèle la migration des applications source, si le projet data engineering révèle des systèmes trop contraignants à maintenir en parallèle d'un pipeline moderne.
#Gouvernance des données : data catalog, data lineage, RGPD by design
La gouvernance n'est pas une option ajoutée en fin de projet — elle est intégrée dès la conception du pipeline. Trois raisons pratiques.
Première raison : le RGPD. Les données à caractère personnel traversant les pipelines doivent être identifiées, pseudonymisées si nécessaire, et soumises à des règles de rétention explicites. On implémente le RGPD by design : classification automatique des colonnes sensibles dès l'ingestion, politique de masquage sur les couches bronze et silver, rétention configurable avec purge automatique.
Cloud souverain possible — les données ne quittent jamais le territoire européen.
Deuxième raison : la confiance dans les données gold. Un agent IA qui répond données gold dont personne ne sait d'où elles viennent n'est pas trustable en production. Le data lineage OpenLineage trace chaque transformation, chaque run de pipeline, chaque version de modèle dbt. Quand l'agent renvoie un score de risque client, on sait exactement quelles données source ont alimenté ce score.
Troisième raison : la scalabilité organisationnelle. Sans data catalog Apache Atlas, quand l'ETI ajoute une quatrième équipe utilisant le data lakehouse, elle repart de zéro pour comprendre ce qui existe déjà. Le catalog documente chaque dataset, ses propriétaires, ses usages, ses SLAs de fraîcheur.
Le data engineering banque et le data engineering industrie ont des exigences de gouvernance supplémentaires — nous adaptons le dispositif aux contraintes sectorielles.
#Ce qu'on mesure : de la donnée en silos à l'IA en production
Le KPI central d'un projet de data engineering est simple : dans combien de temps le premier agent IA est-il en production sur des données gold ? Le déroulé type :
- Audit data. Cartographie des sources, évaluation de la qualité, identification des silos bloquants, choix d'architecture.
- Infrastructure et premiers pipelines d'ingestion. Déploiement du stockage objet, configuration d'Airbyte, premiers flux CDC depuis l'ERP et le CRM.
- Transformation dbt et couche gold. Modélisation des entités clés (clients, produits, contrats, transactions), tests Great Expectations, documentation.
- Premier agent IA sur données gold. Pipeline RAG ou fine-tuning selon le cas d'usage.
Les durées dépendent du nombre de sources et de la qualité de la documentation des systèmes source ; elles sont indiquées dans le devis. Nous mesurons le temps de préparation des données par sprint avant et après la mise en place du pipeline automatisé, ainsi que le nombre de sources connectées : c'est sur ces mesures que se décide l'extension du projet.
On ne fait pas de BI/dashboarding Tableau/Power BI en standalone — ce n'est pas notre cœur de métier. On fait du data engineering pour alimenter les agents IA et LLMs. Si votre besoin est d'abord un dashboard de reporting, nous ne sommes probablement pas le bon partenaire pour cette phase. En revanche, si vous voulez aller vers l'IA ensuite, construire la fondation data avec nous dès maintenant évite de refaire le travail.
#Tarification
Prix de départ, hors taxes :
- Audit IA express (1 journée) : à partir de 990 € HT, déduit du projet s'il est lancé dans les trois mois.
- Audit approfondi / audit data (5 jours) : à partir de 2 125 € HT. Cartographie des sources, évaluation de la qualité, choix d'architecture.
- MVP d'agent IA sur données unifiées : à partir de 11 000 € HT.
- Plateforme multi-agents et architecture data complète (plusieurs sources hétérogènes, CDC depuis un ERP legacy, dbt complet, data catalog, RGPD by design, éventuel data mesh partiel, secteur régulé) : à partir de 50 000 € HT.
- Maintenance et évolution : à partir de 750 €/mois.
L'audit data est inclus dans chaque projet. Le chiffrage définitif est remis en 48 h après un premier échange. Voir aussi notre page fine-tuning LLM sur données propriétaires qui s'appuie directement sur la couche gold produite ici.
Questions & réponses
Questions fréquentes sur le data engineering pour ETI
Trois différences structurantes par rapport à un cabinet généraliste ou à une ESN. Première différence : nous faisons du data engineering en vue de projets IA. Nous ne construisons pas des pipelines pour du reporting Power BI ou de la BI classique — nous les construisons pour alimenter des agents IA, des modèles RAG et des LLM fine-tunés. Chaque choix d'architecture (Medallion, Delta Lake, dbt) est fait avec cet objectif final en tête. Deuxième différence : on audite avant de construire. Chaque projet démarre par un audit data — cartographie des sources, évaluation de la qualité, identification des silos. Aucune architecture n'est définie avant cet audit. Troisième différence : la souveraineté est une option que nous savons mettre en place. Les pipelines peuvent être hébergés sur un stockage objet en France, et sur un hébergeur qualifié SecNumCloud pour les secteurs régulés (banque, assurance, énergie).
dbt Core et Apache Spark ne font pas le même travail, et les confondre coûte cher en surarchitecture. dbt Core est un outil de transformation SQL déclaratif — il prend des données déjà ingérées dans votre data warehouse ou lakehouse, et les transforme via des requêtes SQL versionées en Git, testées automatiquement et documentées. C'est notre outil par défaut pour la couche de transformation silver et gold dans la Medallion Architecture. Avantage : maintenable par les équipes data internes, infrastructure légère, pas de cluster à gérer. Apache Spark 3.5 intervient sur des volumétries que dbt ne peut pas traiter confortablement — typiquement sur de très gros volumes par batch, ou pour les transformations complexes de feature engineering ML qui nécessitent du traitement distribué. Dans beaucoup de projets ETI, dbt Core seul suffit. On n'introduit Spark que si la volumétrie ou la complexité des transformations le justifie réellement. Le surarchitecture est un anti-pattern classique en data engineering — il alourdit la maintenance sans apporter de valeur.
Le CDC (Change Data Capture) est la technique d'ingestion la moins intrusive pour les systèmes source en production — c'est pour ça qu'on l'utilise systématiquement sur les ERP et bases legacy des ETI. Au lieu d'interroger la base source par des requêtes SELECT qui chargent le système, le CDC lit le journal de transactions de la base de données (transaction log Oracle, WAL PostgreSQL, SQL Server CDC natif). Il capture uniquement les changements — insertions, modifications, suppressions — sans jamais toucher aux tables source. L'outil que nous utilisons pour le CDC : Debezium, déployé sur Kafka ou directement via le connecteur Airbyte CDC. Pour Oracle Forms legacy sans CDC natif activé, on utilise une table de timestamps ou de séquences comme marqueur de changement — moins élégant mais fonctionnel. L'impact sur les performances du système ERP source est mesuré avant la mise en production.
La Medallion Architecture est une structure de data lakehouse en trois couches nommées par métaphore sur les métaux précieux. La couche bronze reçoit les données brutes exactement comme elles arrivent des sources — sans transformation, sans nettoyage. C'est la couche d'archivage fidèle qui permet de rejouer tous les traitements en cas d'erreur. La couche silver nettoie, normalise et enrichit : déduplication des clients, standardisation des formats de date, jointures entre sources pour créer des entités cohérentes (un client = un seul enregistrement cross-systèmes). La couche gold contient les agrégats et modèles métier directement consommables par les agents IA, les LLMs et les équipes analytiques — par exemple, un dataset client avec scoring de risque, historique d'achats agrégé et indicateurs de churn calculés. Cette architecture est recommandée pour les ETI pour trois raisons pratiques : elle isole les problèmes (une erreur de transformation en silver n'efface pas le bronze), elle est documentée par les équipes dbt et Delta Lake et largement connue des data engineers du marché, et elle produit une couche gold directement exploitable par les agents IA sans préparation supplémentaire.
La conformité RGPD est intégrée dès la conception du pipeline — pas ajoutée après coup. Cinq mesures systématiques sur chaque projet. Un : classification automatique des colonnes sensibles à l'ingestion via Apache Atlas. Les champs contenant des données personnelles (nom, email, IBAN, numéro de sécurité sociale) sont identifiés et taggés dans le data catalog avant d'entrer dans la couche bronze. Deux : pseudonymisation configurable en couche silver — les identifiants personnels sont remplacés par des clés hachées, les valeurs sensibles sont masquées selon le profil d'accès de l'utilisateur. Trois : politique de rétention avec purge automatique — chaque dataset gold a une durée de vie configurable, les données périmées sont supprimées automatiquement des trois couches. Quatre : hébergement en France sur un stockage objet, données ne quittant pas le territoire de l'Union européenne. Cinq : AIPD (Analyse d'Impact relative à la Protection des Données) systématique avant go-live sur les projets traitant des données sensibles — obligatoire en secteur santé, banque, assurance, fortement recommandé ailleurs.
Les prix de départ sont publiés : audit approfondi à partir de 2 125 € HT, MVP d'agent IA à partir de 11 000 € HT, plateforme multi-agents à partir de 50 000 € HT. Le budget d'un projet de data engineering dépend de trois variables principales. La complexité des sources : connecter quelques sources homogènes (Salesforce + SAP moderne + PostgreSQL) est radicalement différent de connecter de nombreuses sources incluant un Oracle Forms ancien, un AS/400 actif et plusieurs fichiers Excel partagés. Le périmètre de la gouvernance : un projet avec audit data, lakehouse Delta Lake et Great Expectations représente un effort différent d'un projet incluant en plus Apache Atlas complet, OpenLineage, classification RGPD multi-domaines et hébergement SecNumCloud. Le volume de données et la criticité temps réel : ingestion batch quotidienne ou CDC quasi-temps réel sur plusieurs sources en parallèle. Le chiffrage définitif est remis en 48 h après un premier échange.
Parlons de votre projet
Un devis chiffré, sans engagement
Décrivez votre besoin en deux minutes : un consultant senior vous répond avec une première estimation et les prochaines étapes.
- Réponse sous 24 h ouvrées
- Sans engagement
- Un consultant senior vous répond