Data en 2026 : la grande scission
On est en train de vivre un moment charnière pour les équipes data. Une vraie ligne de fracture sépare les équipes qui livrent vite de celles qui accumulent du retard. Et l'écart se creuse chaque trimestre.
Deux mondes en train de diverger
D'un côté, des équipes qui ont adopté un workflow LLM-first : elles travaillent avec Claude Code, ChatGPT Codex, ou équivalent. Elles écrivent du SQL, du YAML, du Python. Elles versionnent tout dans Git. Elles itèrent à une vitesse qui aurait semblé absurde il y a 18 mois.
De l'autre, des équipes qui continuent à opérer dans des interfaces graphiques propriétaires — ETL drag-and-drop, outils BI où chaque modification passe par 14 menus déroulants. Ces équipes ne manquent pas de compétences. Mais elles sont en train de se faire distancer sans s'en rendre compte.
Si les utilisateurs de l'IA pour des tâches quotidiennes de développement expriment un ressenti positif, les chiffres le montrent aussi :
- DORA Report 2025 : 90% des professionnels tech utilisent l'IA quotidiennement.
- Stack Overflow Survey 2025 : 84% des développeurs utilisent ou prévoient d'utiliser des outils IA.
- Google RCT interne : les développeurs avec accès aux outils IA complètent leurs tâches 21% plus vite.
- Étude multi-entreprises (Microsoft, Accenture, Fortune 100) : +26% de productivité en moyenne, jusqu'à +39% pour les juniors.
Mais la stat qui compte, c'est l'écart : les top adopters économisent plus de 10 heures par semaine, pendant que d'autres n'en tirent quasiment rien. L'IA est un amplificateur — elle amplifie les bonnes pratiques autant que les mauvaises.
Les outils legacy sont des boîtes noires pour l'IA
Le problème d'Informatica ou Talend n'est pas qu'ils soient de mauvais outils (quoi que 🤓). C'est qu'ils ont été conçus pour un monde où un humain clique dans une interface. Et ce monde est en train de disparaître.
Quand votre logique métier est encodée dans des flows graphiques propriétaires, stockée dans du XML illisible, sans version control natif, sans tests automatisés, sans documentation exploitable — un LLM ne peut rien en faire. Et l'humain qui travaille dans cet environnement est tout aussi bridé : pas d'automatisation possible, pas de collaboration avec l'IA, chaque tâche reste manuelle. C'est le point crucial. Ces outils sont des boîtes noires pour l'IA. Et dans un monde où l'IA devient le principal levier de productivité, être une boîte noire, c'est être un frein.
Les chiffres de dbt Labs / Infinite Lambda sont éloquents : les équipes sur des ETL legacy passent 80% de leur temps en maintenance et 20% à créer de la valeur. La Macif est passée d'Informatica à dbt : temps de traitement de 2h à 5min, licences de 1M€ à 200K€/an. Datafold estime le marché des migrations ETL legacy à plus de 10 milliards de dollars — un indicateur clair de la dette technique accumulée dans l'industrie.
Everything as code — cette fois c'est différent 🤓
On parle beaucoup de "BI as code". Mais le mouvement est bien plus large. Ce qu'on vit, c'est le passage à everything as code. La raison est nouvelle et fondamentale : tout ce qui est sous forme de code peut être conçu, développé, maintenu et débuggé par des agents IA.
C'est l'insight clé. Quand on dit "as code", on dit en réalité "as text" — et le texte, c'est le langage natif des LLM. Chaque pan du stack data qui passe en mode code devient instantanément accessible à un agent IA. Chaque pan qui reste en mode clic-bouton reste dans l'angle mort. Oui, il existe des alternatives : plugins Chrome, Atlas, ou ces bons vieux outils d'automatisation basés sur Selenium. Techniquement, on peut faire cliquer un agent dans une interface graphique. Mais soyons honnêtes : parmi ceux qui ont fait du Selenium une fois dans leur vie, qui a envie d'en refaire ?
Concrètement, everything as code, c’est :
Infrastructure as code : Terraform, Pulumi. Un agent IA peut lire une config Terraform, diagnostiquer un problème de sizing, proposer un fix, et ouvrir la PR. À la souris dans la console AWS c’est une autre ambiance.
Pipelines as code : dbt, SQLMesh. Du SQL dans des
.sql, des configs en YAML. Claude Code peut lire un projet dbt entier, comprendre la logique, écrire un nouveau modèle, ajouter les tests, mettre à jour la doc — en quelques minutes.BI as code : Comme evidence.dev. De la BI en Markdown + SQL. Vos rapports sont des fichiers
.md versionnés dans Git, avec des requêtes SQL inline et des visualisations auto-générées. Open-source, déployable sur Vercel. Un agent IA peut créer un rapport Evidence de A à Z : requêtes, visualisations, narratif autour des chiffres. Demandez la même chose à un agent sur un dashboard Tableau — on en reparle 🤌.Orchestration as code — Airflow, Dagster, Prefect. Des DAGs en Python, des schedules en YAML. Lisibles, testables, modifiables par un LLM.
Data quality as code — Great Expectations, Soda. Des règles en YAML ou Python. Un agent peut analyser vos données, inférer les bonnes règles de validation, et les écrire pour vous.
Documentation as code — dbt docs, MkDocs, les READMEs. Tout ce qui est en Markdown, un LLM peut l'enrichir, le corriger, le maintenir à jour. La documentation que personne n'a jamais le temps de faire — l'agent la fait.
Le pattern est toujours le même : code → versionné → testable → lisible par un LLM → automatisable par un agent. C'est une chaîne. Si un maillon manque — si votre outil n'est pas "as code" — l'agent s'arrête, et c'est l'humain qui reprend la souris.
MCP : le protocole qui connecte les agents au monde ?
Le Model Context Protocol (MCP), lancé par Anthropic, hébergé à la Linux Foundation, adopté par OpenAI et Google, c'est le chaînon manquant. Le standard qui connecte les agents IA à vos systèmes. Snowflake, BigQuery, Databricks — tous proposent déjà des serveurs MCP.
Sans MCP ou équivalent, un outil est un silo. Avec, il devient un outil que l'agent peut utiliser. MCP n'a pas l'air trop mal parti — adoption rapide, gouvernance ouverte, soutien des trois gros. Mais même si MCP disparaissait demain, le mouvement de fond resterait le même : au minimum, un outil qui expose une CLI est un outil qu'un agent peut piloter. Une CLI, c'est du texte en entrée, du texte en sortie — exactement ce que les LLM savent faire. Les outils qui n'ont ni API, ni MCP, ni même une CLI — juste une interface graphique — deviennent invisibles pour les agents. Et invisible, dans ce contexte, veut dire condamné.
Le coût de production s'effondre — et ce qu'on peut délivrer change radicalement 🤔
Ce qui prenait des jours prend maintenant des heures. Les cas sont documentés. Explorer une nouvelle codebase ? Avant : 1 à 2 semaines. Maintenant : 30 minutes avec Claude Code. Tests unitaires d'un pipeline dbt ? Avant : une journée. Maintenant : 1 à 2 heures, tests + doc inclus. Migration de framework ? Des cas documentés en 24 heures là où on comptait un mois.
Plus votre stack est en code, plus la surface d'action de l'agent est large, plus les gains s'accumulent sur toutes les tâches — parce que l'agent peut naviguer d'un bout à l'autre de la chaîne sans tomber sur une boîte noire.
Ça a deux conséquences majeures sur ce qu'on délivre concrètement.
D'abord, ça renverse l'équation Make vs Buy. Pendant des années, on achetait Tableau à 70$/mois/utilisateur parce que développer un front de dataviz en interne aurait pris des semaines. On achetait des couteaux-suisses chers et surdimensionnés dont on utilisait 20% des fonctionnalités. Ce raisonnement ne tient plus. Quand un agent peut construire en quelques heures un front React qui tape sur BigQuery, avec exactement le design, les graphiques et le wording que le client veut — pourquoi payer une licence pour un outil générique ? Le livrable est sur-mesure et c'est du code : versionné, maintenable, modifiable par un agent. Le "Buy" se justifie encore pour certains sujets critiques, mais pour l'interface, la visualisation, le reporting — le rapport de force s'inverse.
Ensuite, ça change ce qu'une équipe data peut — et doit — délivrer. Pendant longtemps, le livrable par défaut d'une équipe data c'était un dashboard. Un client posait une question, on construisait un dashboard. Il posait une autre question, on ajoutait un onglet. Puis un filtre. Puis un deuxième dashboard. On se retrouvait à maintenir des dizaines de vues que plus personne ne regarde, dans un outil SaaS à 70$/mois/utilisateur.
Ce réflexe est obsolète. Quand le coût de production chute, le champ des possibles explose, et le dashboard n'est plus qu'une option parmi d'autres :
Un client veut explorer ses données librement ? On déploie un chatbot gouverné type Omni — des "topics" curés avec leur semantic layer, leurs métriques, leurs relations, et l'utilisateur pose ses questions en langage naturel. L'IA génère le bon SQL grâce au contexte métier embarqué. Ce n'est pas un chatbot générique qui hallucine — c'est un chatbot qui respecte vos définitions métier. 80% des "demandes de dashboard" sont en réalité des questions ponctuelles : le conversationnel les traite mieux, plus vite, et sans maintenance.
Un client veut une interface métier spécifique ? On construit une data app sur-mesure en quelques heures — un front React branché sur le warehouse, exactement calibré sur son besoin, dans sa charte. Quelque chose qu'on n'aurait jamais proposé avant parce que le coût de développement ne le justifiait pas.
Un client veut un reporting récurrent ? On lui fait un rapport Evidence ou Hex — du Markdown + SQL versionné dans Git, auto-généré, déployé automatiquement. Pas un PDF exporté d'un outil.
Le dashboard classique garde sa place pour le monitoring opérationnel et les KPIs affichés en continu. Mais il n'est plus le livrable par défaut. Les produits data de 2026, ce sont des data products sur-mesure — chatbot, app, rapport, API — construits en jours, pas en semaines, adaptés au besoin exact plutôt que contraints par les limites d'un outil générique.
Ce que ça change pour nous
Concrètement, notre rôle va être d'accompagner nos clients vers ce nouveau monde :
1. Passer en everything-as-code. Sortir des ETL GUI. Passer sur dbt, Evidence, Hex, des pipelines en code… C'est la condition préalable à tout le reste — tant que la logique métier est dans des interfaces propriétaires, l'IA ne peut rien amplifier. Chaque composant migré vers du code est un composant qui devient pilotable par un agent.
2. Repenser ce qu'on délivre. 80% des demandes de dashboard sont des questions ponctuelles. Le conversationnel gouverné les traite mieux. Et quand le besoin justifie une interface, la construire sur-mesure est désormais plus rapide et moins cher que de paramétrer un outil générique.
3. Arbitrer Make vs Buy avec les nouveaux coûts. Chaque renouvellement de licence SaaS devrait déclencher la question : est-ce qu'un agent ne produit pas ça en quelques heures, en mieux, en sur-mesure ?
4. Former les équipes au workflow LLM. Travailler dans un terminal, reviewer du code généré, construire des prompts systémiques réutilisables. Le data platform engineer de 2026 écrit de moins en moins de code lui-même — il pilote un agent qui écrit du code pour lui.