Aller au contenu
Tous les articles
2 mai 2026Virgil GuivigouSenior Consultant10 min

Comment l'IA et les LLM impactent les projets data

L'IA ne remplace pas la data engineering. Elle la transforme, la déplace, et redessine les frontières entre métier et plateforme. Retour terrain sur 12 missions data assistées par LLM en 2025.

Comment l'IA et les LLM impactent les projets data

Pendant 12 mois, nous avons accompagné douze équipes data — banque, énergie, retail, secteur public — en injectant systématiquement des LLM dans leurs workflows. Conclusion qui surprendra peut-être : les LLM ne raccourcissent pas le projet data, ils le réorientent. Ce qui prenait 8 semaines en prend 6, mais la nature du travail a changé. Voici ce qu'on observe sur le terrain.

Ce qui a accéléré (et de combien)

La phase d'exploration : −60% de temps

Sur les 4 premières semaines d'un projet data classique, 60% du temps va à comprendre des sources de données opaques — des tables ERP avec 400 colonnes mal documentées, des fichiers CSV historiques où chaque ligne raconte une histoire différente, des vues SQL héritées de quelqu'un parti il y a 5 ans.

Ce qu'on fait maintenant : on charge les samples + les commentaires de schéma dans un LLM et on lui demande de construire un dictionnaire de données provisoire. L'output n'est pas parfait (typiquement 70-80% correct), mais la base de discussion avec les métiers est immédiate. Avant : 3 semaines d'interview pour un MCD. Maintenant : 4 jours pour un brouillon, puis 1 semaine de validation métier.

La rédaction de SQL complexe : −50%

Les LLM 2026 (Claude 4.6, GPT-4.7) génèrent du SQL Snowflake, BigQuery, Postgres avec une qualité supérieure à un junior data engineer. Pas parfait — souvent oubli des NULL handling ou des fenêtres de partitionnement — mais le squelette est juste 9 fois sur 10.

Notre process : un consultant senior écrit la spec en français + dessine le résultat attendu, le LLM produit le SQL, le consultant relit + ajuste. Ce qui prenait 4h en prend 1h30. Sur des migrations de 200+ requêtes, c'est 70+ jours-homme économisés.

La doc technique : −80%

Tout : README de pipelines, runbooks d'incidents, specs métier de tableaux de bord. Le LLM prend le code comme entrée, produit la doc, le consultant relit. La doc est désormais à jour parce qu'elle ne coûte plus rien à régénérer après un refactor. C'est probablement le gain le plus durable : la dette de documentation cesse d'être une variable.

Ce qui n'a pas accéléré

Les décisions de modélisation

Choisir entre un schéma en étoile et un Data Vault, entre un grain par transaction et un grain par événement métier — un LLM peut résumer les tradeoffs, mais pas trancher. Ces décisions dépendent d'une connaissance du métier que le LLM n'a pas. Et tenter de la lui transférer (en stuffant le contexte avec 50 docs) produit des recommandations génériques sans valeur.

Conséquence pratique : la phase de modélisation prend toujours 2-3 semaines. Le LLM est utile pour formaliser ce qu'on a décidé, pas pour décider.

La gouvernance et le RGPD

Les LLM ne savent pas (ou très imparfaitement) ce qui est PII dans votre organisation. Demander à un LLM de catégoriser 400 colonnes en personal/sensitive/business produit ~85% de bonne classification, mais les 15% qui restent sont ceux qui comptent. Sur ces sujets, on garde un humain dans la boucle systématiquement.

Le débogage des pipelines en production

Quand un pipeline DBT casse à 4h du matin parce que la source upstream a renommé une colonne, le LLM aide à formuler une hypothèse mais ne remplace pas l'investigation. Lire les logs, comprendre le diff de schéma, valider l'impact aval — ça reste du travail humain. Au mieux, le LLM accélère la rédaction du post-mortem.

La nouvelle structure d'un projet data en 2026

Voici comment on structure désormais un projet data assistant LLM, sur 12 semaines pour une ETI :

| Semaine | Phase | Levier LLM | Charge humaine | | ------- | ------------------------- | ----------- | -------------- | | S1-S2 | Cadrage métier + scoping | Faible | Forte | | S3 | Exploration sources | Forte | Faible | | S4-S5 | Modélisation conceptuelle | Faible | Forte | | S6-S7 | Implémentation pipelines | Moyenne | Moyenne | | S8-S9 | Tests + qualité | Moyenne | Forte | | S10 | Dashboards & restitution | Forte | Moyenne | | S11 | Hardening + RGPD | Faible | Forte | | S12 | Run + documentation | Forte | Faible |

Charge totale : passée de 100 j/h à 70 j/h. Mais surtout, la répartition a changé : plus de temps sur le métier, moins sur la plomberie.

Trois écueils qu'on voit sur le terrain

1. Croire que le LLM remplace l'expertise data

Les juniors qui pensent qu'un LLM les dispense d'apprendre les fondamentaux (normalisation, partitionnement, fenêtrage) produisent des pipelines qui marchent au sample mais cassent à l'échelle. Le LLM amplifie un savoir, il ne le remplace pas.

2. Mettre les credentials data dans le contexte LLM

Quelques équipes que nous avons audit avaient pris l'habitude de coller leur connection string Postgres dans ChatGPT pour debug. Ces credentials sont maintenant dans des logs OpenAI quelque part. Notre règle ferme : aucune credential, aucune donnée client réelle dans le contexte LLM. Si le LLM a besoin de comprendre un schéma, on lui donne le DDL anonymisé.

3. Ignorer le coût de l'inférence sur les pipelines automatisés

Brancher un LLM en hot path sur un pipeline data (extraction d'entités, classification) sans budget = facture imprévisible. Sur un client en 2025, un pipeline qui classifiait 50 000 tickets/jour a fait exploser le budget Bedrock à 4 200 €/mois là où la prévision était à 800 €.

Le fix : toujours mesurer en pilote, fixer un max_cost_per_run, et avoir un fallback non-IA pour les périodes de pic.

Notre recommandation aux DSI et CDO

Trois actions pour 2026 :

1. Formez vos data engineers seniors aux LLM en priorité. Pas les juniors. Un senior expérimenté + LLM = ×2.5 productivité. Un junior + LLM = ×1.2, et il ne progresse pas.

2. Investissez dans l'observabilité LLM. Datadog LLM Observability, Langfuse, ou un MLflow custom — peu importe l'outil, vous voulez tracer chaque appel, son coût, et son taux de succès. Sans ça, le LLM est une boîte noire qui dérive silencieusement.

3. Rejouez votre data catalog. Un LLM peut générer un MCD à partir d'un dump SQL en quelques heures. Si votre dictionnaire de données est obsolète depuis 3 ans, c'est l'occasion. La dette documentaire s'évapore en un week-end de hackathon.


Cet article s'appuie sur 12 missions data accompagnées par Cloud Skunkworks en 2025-2026, dont 9 ont intégré un LLM dans le workflow d'au moins un consultant. Vous voulez challenger votre roadmap data ? Réservez un brief.

Data engineeringLLMPower BIDatabricksAnalytics

Faisons connaissance

Faites avancer vos projets avec nous.

Un brief de trente minutes pour comprendre votre contexte, challenger l'approche et identifier où nous pouvons créer le plus de valeur.