Par Andrew Tan
Pourquoi j'écris ceci
Parce que l'IA est très en vogue en ce moment, certains CTO se demandent : "L'IA devrait-elle remplacer la moitié de notre équipe d'ingénierie des données ?"
C'est l'état de l'IA dans l'ingénierie des données actuellement. Tout le monde publie du contenu enthousiaste. Personne n'est précis. Voici donc mon point de vue sur le sujet :
Ce que l'IA aide réellement
La génération de SQL est le gain le plus évident. Les outils de type Copilot réduisent le temps nécessaire pour rédiger une première ébauche de requête analytique de 50 à 70 % pour les ingénieurs ayant de solides bases en SQL. Vous devez toujours la réviser. Vous devez toujours savoir à quoi la réponse devrait ressembler. Mais le problème de la page blanche a disparu.
La documentation des schémas est beaucoup plus rapide. Passer de "nous avons 400 tables" à "nous avons documenté 400 tables" prenait autrefois des mois de travail d'analyste. Avec de bons outils LLM, les équipes peuvent accomplir cela en quelques semaines. La documentation n'est pas parfaite, mais elle est suffisamment bonne pour être utile, ce qui n'était souvent pas le cas auparavant.
L'analyse ad hoc a changé de manière significative pour les non-ingénieurs. Les analystes commerciaux qui avaient l'habitude de déposer des tickets pour "pouvez-vous me rédiger une requête qui…" peuvent désormais obtenir eux-mêmes des réponses fonctionnelles à des questions simples. C'est une véritable productivité. C'est aussi une réduction significative du travail interrompu pour les équipes d'ingénierie des données.
Ébauches de révision de code. Ce n'est pas un remplacement pour la révision, mais attraper les choses évidentes — jointures non indexées, vérifications de null manquantes, incompatibilités de type — avant qu'un humain ne les examine permet de gagner du temps globalement.
Ce sont des gains réels et ils comptent. Je ne veux pas les minimiser.
Ce que l'IA ne peut pas gérer de manière fiable
C'est là que l'écart entre les revendications des fournisseurs et la réalité de la production s'ouvre.
Évolution des schémas à grande échelle
La partie la plus difficile du maintien des pipelines de production n'est pas d'écrire le code — c'est de savoir quoi faire lorsqu'un système en amont change un type de champ, déprécie une colonne ou commence à envoyer des données dans un format différent. Cela nécessite de comprendre la logique métier derrière les données, les consommateurs en aval, le contexte historique de pourquoi le champ existe. Un LLM qui n'était pas dans la pièce lorsque ces décisions ont été prises ne peut pas raisonner de manière fiable sur la bonne réponse. Il vous donnera quelque chose qui semble correct. Souvent, ce n'est pas le cas.
Traitement de flux avec état
Une équipe peut passer trois mois à essayer de faire en sorte qu'un LLM implémente correctement une agrégation fenêtrée avec gestion des arrivées tardives pour leur pipeline de détection de fraude en temps réel. Le LLM pourrait écrire le code. Le code fonctionne également. Il produit des réponses incorrectes dans des cas limites qui n'apparaissent que dans la production, dans des conditions d'ordre spécifiques, les jours avec des volumes d'événements inhabituels. Ces bogues sont dures à traiter — ils ne génèrent pas d'erreurs, ils corrompent simplement vos métriques en silence. Le modèle n'a aucun moyen de tester sa propre sortie contre les cas limites réels qu'il rencontrera.
Récupération après échec en production
Lorsqu'un consommateur Kafka est en retard de 48 heures et que vous devez décider de rejouer, de supprimer ou de dédupliquer — ce n'est pas un problème de génération de code. C'est un jugement qui nécessite de connaître votre entreprise, vos SLA, et le coût de chaque option. Je n'ai pas encore vu un LLM prendre cette décision correctement sans un encadrement humain significatif.
Un ingénieur principal dans une entreprise de cybersécurité m'a dit : "Nous avons atteint environ 70 % d'automatisation sur nos modèles ETL standard. Les 30 % restants sont les choses qui cassent réellement en production." Il ne se plaignait pas. Il comprenait pourquoi. Mais les 30 % sont ce qui garde les ingénieurs en données employés.
Le problème de l'"automatisation à 80 %"
Gartner a publié une prédiction l'année dernière selon laquelle 80 % du travail d'ingénierie des données serait affecté d'ici 2027. Je comprends pourquoi ils l'ont écrit.
Voici le problème avec les 80 % : les 80 % dont ils parlent sont de l'échafaudage. Des modèles. Des premières ébauches. La partie qui est réellement automatisable à 80 %, par exemple, est la partie qui était déjà relativement rapide.
Ce qui reste, c'est les 20 % qui prennent 80 % du temps — déboguer pourquoi les données semblent incorrectes, négocier les changements de schéma avec les équipes en amont, raisonner sur la fiabilité du pipeline dans des conditions que personne n'avait anticipées. Ces 20 % sont également les 20 % où une mauvaise réponse est coûteuse.
Je ne dis pas cela pour être pessimiste. Les 80 % comptent. Libérer les équipes d'ingénierie de l'échafaudage est réellement précieux. Mais les équipes qui planifient un monde où cette automatisation signifie moins d'ingénieurs font un pari spécifique que les problèmes coûteux deviendront également plus faciles. Ils pourraient. Je n'en vois pas encore la preuve.
Ce que je dis aux équipes envisageant des réductions d'effectifs
Ne le faites pas encore. Pas parce que la technologie n'est pas réelle, mais parce que vous pariez sur la mauvaise variable.
Les équipes qui tirent le meilleur parti des outils d'IA ne sont pas celles qui réduisent les effectifs — ce sont celles qui prennent le même effectif et le dirigent vers des problèmes plus difficiles. Les ingénieurs qui passaient leurs journées sur des travaux ETL de routine travaillent maintenant sur des cadres de qualité des données, la gouvernance des schémas, la fiabilité des pipelines en temps réel. La production par ingénieur est plus élevée. La qualité de la production est plus élevée. L'équipe est plus difficile à remplacer, pas plus facile.
C'est l'histoire. L'IA est un multiplicateur de productivité pour les ingénieurs en données. Ce n'est pas L'ingénieur en données.
Un aperçu simple
Je sais que j'ai dit que j'éviterais le format de tableau comparatif. Mais celui-ci est vraiment le moyen le plus clair de le montrer :
| Tâche | L'IA aide | L'IA a du mal |
|---|---|---|
| Génération de SQL | Premières ébauches, 50-70% plus rapide | Logique complexe avec des règles métier subtiles |
| Documentation des schémas | Première passe, semaines pas mois | Sémantique précise sans contexte métier |
| Analyse ad hoc | Questions simples pour les non-ingénieurs | Questions nécessitant un contexte inter-systèmes |
| Code de pipeline | Modèles, modèles standard | Logique avec état, gestion des cas limites |
| Évolution des schémas | — | Presque entièrement un jugement humain |
| Récupération après échec | — | Nécessite des connaissances métier + opérationnelles |
| Débogage en production | — | Les LLM ne connaissent pas votre historique spécifique |
La colonne de gauche est réelle. La colonne de droite est la raison pour laquelle les équipes d'ingénierie des données existent toujours.
Où layline.io s'intègre
Je vais être direct : les gains de productivité de l'IA que j'ai décrits ci-dessus sont plus faciles à capturer lorsque vos pipelines ont une structure explicite que les LLM peuvent comprendre et étendre.
Chez layline.io, nous construisons des pipelines avec une configuration déclarative — la logique est dans des opérateurs structurés, pas intégrée dans du code personnalisé (sauf pour le Javascript ou Python occasionnel ici et là et seulement là où c'est vraiment nécessaire). Cela s'avère bien se marier avec le développement assisté par IA. Lorsqu'un ingénieur demande à un LLM d'ajouter une étape de traitement, le LLM peut raisonner clairement à ce sujet. Lorsque quelque chose casse, l'échec est dans un endroit connu plutôt qu'enfoui dans du code sur mesure.
Ce n'est pas la raison pour laquelle nous l'avons construit de cette façon. Nous l'avons construit de cette façon parce que les pipelines déclaratifs sont plus faciles à déboguer et à maintenir pour les humains. L'affinité avec l'IA s'est avérée être un effet secondaire.
Mais cela signifie que les équipes qui construisent sur une base structurée tirent plus parti des outils d'IA que les équipes travaillant dans du code personnalisé. Quelque chose à considérer lorsque vous faites des choix architecturaux qui compteront dans deux ans.
La question à poser à votre équipe
Essayez ceci : choisissez vos cinq derniers incidents de données. Pour chacun d'eux, demandez-vous si une IA aurait pu le prévenir ou le diagnostiquer plus rapidement.
Pour la plupart des équipes, la réponse est "peut-être 1 sur 5." Les quatre autres sont des problèmes qu'un LLM ne peut pas raisonner de manière fiable — une logique métier incorrecte qui est techniquement un code correct, un changement de schéma d'une équipe en amont que personne n'a annoncé, un cas limite dans le traitement de flux qui ne se manifeste qu'à des volumes d'événements spécifiques.
Si vous évaluez des outils d'IA, c'est votre référence. Pas "l'IA va-t-elle changer l'ingénierie des données" — bien sûr qu'elle le fera. Mais "l'IA éliminera-t-elle les problèmes qui nous font réellement mal ?" Cette réponse est non, pas encore, et probablement pas sans que quelque chose change qui n'a pas changé.
Andrew Tan est un entrepreneur en série et fondateur de layline.io, construisant une infrastructure de traitement de données d'entreprise qui gère à la fois les charges de travail par lots et en temps réel à grande échelle.
