Data Engineering ETI — La fondation data de tous vos projets IA

#Pourquoi le data engineering est la vraie fondation de tout projet IA en 2026

Une anecdote qu'on vit à chaque troisième 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 l'Oracle Forms legacy de 2003 que personne n'ose migrer. Trois fichiers Excel partagés sur un serveur réseau — dont un que seule une assistante de direction sait lire. Et les données de la filiale rachetée en 2021, encore sur leur propre SQL Server. Sept systèmes. Quatre formats de date incompatibles. Aucun identifiant client commun entre les sources.

Ce n'est pas un cas exceptionnel. C'est la norme dans les ETI françaises de 200 à 2000 collaborateurs.

En 2026, 70 % des projets IA échouent à cause de la donnée, pas à cause du modèle. On le voit à chaque audit de cadrage Nehos. Le modèle LLM est rarement le problème — Mistral Large 2, Claude Sonnet 4, 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.

Nehos a fait un choix structurant : 100 % des 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 chez nous. Ce n'est pas une contrainte — c'est la condition pour que le projet ne s'arrête pas au bout de 6 mois sur un problème de qualité data.

#Les 5 problèmes data les plus fréquents chez les ETI françaises

#1. La fragmentation des sources

ERP, CRM, bases legacy Oracle ou SQL Server, fichiers Excel, données de filiales rachetées — une ETI de 500 collaborateurs opère typiquement entre 8 et 18 sources de données métier hétérogènes. Sur les projets Nehos 2024-2025, on connecte en moyenne 12 sources par projet. 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

Les systèmes Oracle Forms des années 2000 fonctionnent encore dans 40 % des ETI industrielles françaises. 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 Nehos.

#4. La qualité de données dégradée

Champs null à 40 %, 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 de 6 mois avant la migration vers un lakehouse.

Lakehouse (Delta Lake / Apache Iceberg + Medallion Architecture) — la recommandation Nehos pour 80 % 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). Délai de mise en production : 8 à 10 semaines.

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 ETI de 1000+ collaborateurs 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 (6 à 12 mois), 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 Nehos en 2026 est 100 % open source, 100 % souveraine :

• 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. 300+ connecteurs disponibles, développement connecteur custom 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 (> 100 Go de données traitées 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 souverain français compatible S3. SecNumCloud disponible pour les données sensibles. Coût maîtrisé vs AWS S3 ou Azure Blob Storage.
• 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 standardisées Nehos :

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 (toutes versions jusqu'à 11g), 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 OVHcloud par défaut — 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.

#ROI mesuré : de la donnée silos à l'IA en production en 3 mois

Sur les projets Nehos 2024-2025, le KPI central pour évaluer le succès d'un projet data engineering est simple : dans combien de temps le premier agent IA est-il en production sur des données gold ?

Réponse mesurée : 3 mois en moyenne. Décomposition standard :

• Audit data : 5 jours. Cartographie des sources, évaluation qualité, identification des silos bloquants, choix d'architecture.
• Setup infrastructure + premiers pipelines d'ingestion : 3 semaines. Déploiement OVHcloud Object Storage, configuration Airbyte, premiers flux CDC depuis ERP et CRM.
• Transformation dbt + couche gold : 5 semaines. Modélisation des entités clés (clients, produits, contrats, transactions), tests Great Expectations, documentation.
• Premier agent IA sur données gold : 4 semaines supplémentaires (pipeline RAG ou fine-tuning selon le cas d'usage).

-78 % de temps de préparation data après mise en place du pipeline automatisé. Avant le projet, l'équipe data d'une ETI assurance passait 14 jours par sprint à préparer les données pour chaque analyse. Après le pipeline Delta Lake + dbt : 3 jours par sprint. Les 11 jours récupérés ont été réinvestis dans la modélisation IA.

12 sources hétérogènes connectées en moyenne sur un projet data engineering ETI Nehos. Le record sur 2025 : 23 sources sur un groupe industriel avec 4 filiales et 3 générations de systèmes ERP.

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, Nehos n'est 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 : à partir de 1 746 € HT

Fourchette 2026 pour un projet data engineering ETI Nehos :

• 212 k€ — audit data + mise en place lakehouse Delta Lake sur 2-4 sources, couche bronze/silver/gold, gouvernance de base (Great Expectations + OpenLineage). ETI 200-400 collaborateurs, premier projet IA ciblé.
• 171 k€ — 5 à 12 sources hétérogènes, CDC depuis ERP legacy, dbt complet avec 15-30 modèles, Apache Atlas data catalog, RGPD by design complet. ETI 400-1000 collaborateurs.
• 712 k€ — architecture data mesh partielle, 12+ sources, Spark 3.5 pour les transformations volumineuses, gouvernance complète multi-domaines, intégration cloud souverain OVHcloud SecNumCloud, secteur régulé (banque, assurance, énergie). ETI 1000-2000 collaborateurs.

Audit de cadrage data inclus dans chaque projet (5 jours). MCO mensuel post-livraison : à partir de 5 k€/mois selon la volumétrie et la criticité des pipelines. Voir aussi notre page fine-tuning LLM sur données propriétaires qui s'appuie directement sur le data lake gold layer produit ici.