Ingénieur de données
Vous construisez l'infrastructure de données et d'IA sur laquelle le reste de l'entreprise tourne. Pipelines, entrepôts, magasins vectoriels, infrastructure de service de modèles, observabilité : la fondation qui permet aux agents de faire leur travail et aux analystes de produire des insights. L'agent écrit une grande partie du code ; vous concevez l'architecture et portez la fondation.
Le travail
Vous portez l'infrastructure de données et d'IA de l'entreprise. Pipelines ETL, entrepôts de données, systèmes de streaming, magasins vectoriels, infrastructure de service de modèles, livraison de contexte aux agents, observabilité des données. L'agent écrit une grande partie du code ; vous concevez l'architecture, validez que l'infrastructure tient sous charge, et portez la fondation sur laquelle tout le reste dépend.
C'est un travail d'ingénierie distinct de l'ingénierie applicative : la matière est différente (flux de données, pas interactions utilisateur), les modes de défaillance sont différents (corruption silencieuse des données, pas bogues visibles), et les consommateurs sont différents (analystes, agents, utilisateurs internes, pas clients externes directement).
Au quotidien, vous :
- Concevez l'architecture de données. Où vivent les données, comment elles circulent, quels modèles les structurent, comment elles sont accédées à l'échelle. Des choix d'architecture qui composent sur des années.
- Spécifiez les pipelines et l'infrastructure. L'agent implémente ; vous concevez ce qui est implémenté et validez que ça tient.
- Construisez la couche de contexte des agents. Les agents en production ont besoin d'un contexte fiable, à jour et bien structuré. Concevoir le substrat de données qui le soutient est une part substantielle du rôle à l'échelle IA-native.
- Portez la qualité et l'observabilité des données. De mauvaises données corrompent silencieusement tout consommateur en aval. Concevoir une observabilité qui attrape les problèmes avant qu'ils ne se propagent est un travail central.
- Opérez l'infrastructure d'IA. Magasins vectoriels, pipelines d'embeddings, service de modèles, infrastructure d'évaluation : ce sont des systèmes de production de premier ordre avec des caractéristiques spécifiques de fiabilité et de coût.
- Validez à des points de validation gradués par le risque. Les changements de pipeline courants et l'ETL standard passent par une revue agent seule. Les changements de schéma, suppression de données, décisions sensibles au coût, changements liés à la vie privée et modifications d'infrastructure d'IA exigent votre approbation directe.
- Vous associez à l'analyste de données. L'analyste définit les questions et interprète les résultats ; vous vous assurez que la fondation de données répond fiablement. Définitions, instrumentation, attribution : ces choses se co-portent.
- Vous associez aux ingénieurs applicatifs. Leurs fonctionnalités génèrent des données ; ces données circulent dans votre infrastructure ; votre infrastructure nourrit leurs fonctionnalités. La couture compte.
À quoi ressemble le succès
Résultats concrets à ce niveau :
- Fiabilité des pipelines. Les pipelines de données tournent fiablement, la latence est bornée, les défaillances sont attrapées et récupérées. Les consommateurs ne se font pas surprendre par des données manquantes ou corrompues.
- Qualité des données. Les problèmes de qualité, d'instrumentation ou d'étiquetage sont attrapés à la source, pas au consommateur en aval.
- Discipline de coût. Coût de calcul, coût de stockage et coût d'infrastructure d'IA sont visibles, à jour et s'améliorent au fil du temps. Vous pouvez défendre la dépense d'infrastructure par résultat.
- Santé de l'infrastructure des agents. Les agents ont un accès fiable à un contexte frais et bien structuré. Magasins vectoriels, pipelines d'embeddings et infrastructure de service de modèles tournent avec une latence et un coût prévisibles.
- Cohérence d'architecture. Les choix d'architecture de données tiennent sur des années. Les migrations de schéma sont gérables. L'infrastructure vieillit bien plutôt que de s'effondrer sous sa propre complexité.
Ce qui ne compte pas comme succès : pipelines construits, tableaux de bord livrés, technologies adoptées isolées des résultats.
Ce qui rend ce travail intéressant
L'intéressant n'est pas les pipelines eux-mêmes. C'est de siéger à la fondation sur laquelle le reste de l'entreprise dépend de plus en plus.
Votre travail est véritablement porteur. Les analystes dépendent de vous. Les agents dépendent de vous. Les ingénieurs applicatifs dépendent de vous. Le produit dépend de vous. Quand l'infrastructure de données est bien conçue, toute l'entreprise bouge plus vite ; quand elle ne l'est pas, tout le reste peine à compenser.
Vous concevez à plusieurs échelles temporelles. Certaines décisions (schéma, nommage, partitionnement) composent sur des années ; d'autres (réglage de pipeline spécifique) ont besoin d'ajustements trimestriels. Les ingénieurs de données qui peuvent tenir les deux échelles produisent une infrastructure solide.
Les opérations IA-natives ont besoin d'un nouveau substrat de données. Magasins vectoriels, pipelines d'embeddings, infrastructure de service de modèles, livraison de contexte aux agents : ce sont des systèmes véritablement nouveaux conçus en temps réel. Vous participez à trouver les patrons que l'industrie utilisera.
Le travail diagnostique est satisfaisant. Quand les problèmes de qualité de données apparaissent en aval, l'enquête implique souvent le flux, la spécification, l'instrumentation et parfois l'infrastructure elle-même. Le travail de détective est riche.
L'ingénierie de coût est intéressante. Le coût de l'infrastructure de données a des caractéristiques très différentes du coût de l'infrastructure applicative. Stockage vs calcul, lot vs streaming, frais vs périmé, dimensionnalité de vecteurs, choix de modèle d'embeddings : la surface d'optimisation est nouvelle et significative.
Le partenariat transversal devient profond. Avec le travail ETL courant absorbé, vous avez du temps pour un engagement substantiel avec les analystes de données, ingénieurs applicatifs, le produit, l'architecte de flux. Le rôle vit à des intersections productives.
Votre impact compose. Un substrat de données bien conçu fait gagner à l'entreprise des années de travail. Mal conçu, il crée une dette technique qui contraint les décisions pendant des années.
La mobilité de carrière est réelle. Les ingénieurs de données solides au Niveau 3 sont recrutés intensément. Les compétences transférables (architecture, conception système, ingénierie de coût, infrastructure d'IA) sont précieuses entre entreprises et industries.
Ce qui peut ne pas plaire. Votre travail est invisible quand il fonctionne. Personne ne remarque un pipeline qui tourne bien ; on ne remarque que celui qui casse. La reconnaissance est structurelle et silencieuse, pas tapageuse. Les ingénieurs de données qui ont besoin d'un impact direct face à l'utilisateur trouvent parfois le travail distant. Vous travaillez aussi avec des consommateurs (analystes, agents, utilisateurs internes) plutôt qu'avec les clients directement, ce qui peut sembler moins concret que l'ingénierie applicative. Et l'ingénierie de données a historiquement été sous-valorisée par rapport à l'ingénierie applicative dans beaucoup d'entreprises ; bien que les opérations IA-natives changent cela rapidement, la sous-reconnaissance héritée peut encore se manifester dans certaines cultures.
Qui s'épanouit dans ce rôle
Les aptitudes qui comptent le plus sont la pensée systémique, le jugement architectural et la discipline de coût, distinctes des forces d'ingénierie applicative.
Vous pensez en systèmes et en flux. Les données sont en forme de système. Les ingénieurs qui voient naturellement les flux, dépendances et comportements émergents produisent une infrastructure de données solide.
Vous tenez à la justesse plus qu'à la vitesse. De mauvaises données corrompent silencieusement tout l'aval. Les ingénieurs de données qui tiennent à la justesse produisent une infrastructure digne de confiance ; ceux qui optimisent pour la vitesse de livraison produisent des problèmes cachés.
Vous êtes à l'aise avec les longues boucles de rétroaction. Les choix d'architecture montrent leurs conséquences sur des mois et des années. Les ingénieurs de données qui ont besoin d'un retour rapide peinent ; ceux qui peuvent concevoir avec soin et patience produisent de fortes fondations.
Vous tenez la discipline de coût. L'infrastructure de données peut devenir coûteuse rapidement. Les ingénieurs qui traitent le coût comme préoccupation de premier ordre produisent une infrastructure durable ; ceux qui ne le font pas produisent des factures-surprises.
Vous savez lire à travers les consommateurs. Analystes, agents, ingénieurs applicatifs, utilisateurs internes : ils ont des besoins différents des mêmes données. Les ingénieurs qui peuvent tenir plusieurs perspectives de consommateur produisent une infrastructure utile ; ceux qui n'optimisent que pour un seul échouent face aux autres.
Vous écrivez clairement. Documents d'architecture de données, spécifications de schéma, runbooks. Une écriture claire est centrale au rôle.
Vous êtes méfiant des histoires propres. Quand les données semblent trop propres, vous enquêtez. Un scepticisme sain envers vos propres pipelines est essentiel.
Vous vous associez bien avec les spécialistes adjacents. Analyste de données, ingénieur applicatif, ingénieur DevOps, architecte de flux. Les ingénieurs qui peuvent traduire entre ces frontières produisent une infrastructure cohérente.
Moins essentiel qu'avant : la maîtrise d'un outil de données ou d'un cadre ETL spécifique, la capacité d'écrire du SQL complexe à la main, la profondeur dans un magasin de données spécifique. L'agent absorbe ces choses. Le rôle valorise l'architecture, le jugement et la conception.
Compétences à développer pour y arriver
Les aptitudes décrivent la disposition. Les compétences ci-dessous sont ce que vous construisez activement.
Spécification d'architecture de données. Écrire comment les données circulent, où elles vivent, quels modèles les structurent, avec assez de rigueur pour que l'agent puisse construire et que l'équipe puisse étendre. Comment pratiquer : rédigez l'architecture de données pour votre périmètre actuel. Faites-la contester par un pair ; raffinez.
Ingénierie de fiabilité de pipeline. Concevoir des pipelines observables, récupérables et prévisibles sous charge. Comment pratiquer : pour un pipeline, concevez l'observabilité et la récupération avant de construire. Testez en simulant la défaillance.
Pensée coût par résultat. Lire le coût d'infrastructure de données comme une donnée d'ingénierie, pas une donnée financière. Comment pratiquer : mensuellement, auditez les moteurs de coût. Identifiez les trois principales opportunités d'optimisation sans perte de qualité. Implémentez-en une.
Garde du schéma et des définitions. Maintenir des modèles de données cohérents sur lesquels les consommateurs peuvent compter. Comment pratiquer : prenez un schéma central. Écrivez la spécification définitive. Obtenez l'adhésion transversale. La discipline compose.
Conception d'infrastructure d'IA. Magasins vectoriels, pipelines d'embeddings, service de modèles, livraison de contexte aux agents. Comment pratiquer : pour un flux d'IA que votre entreprise opère, documentez l'infrastructure dont il dépend. Identifiez les modes de défaillance. Concevez les contrôles.
Spécification d'observabilité de données. Ce qui se mesure, ce qui déclenche les alertes, quelle est la réponse attendue. Comment pratiquer : pour chaque pipeline, écrivez la spec d'observabilité avant le pipeline. Si la réponse à « comment saurions-nous que c'est cassé ? » est « par les plaintes en aval », la spec n'est pas finie.
Communication transversale. Écrire pour les analystes de données, les ingénieurs applicatifs, le produit, le DevOps, les dirigeants. Comment pratiquer : rédigez une proposition d'infrastructure. Montrez-la à une personne de chaque fonction. Là où ils sont confus, c'est là que l'écriture doit travailler.
Métier de la migration. Changements de schéma, migrations d'infrastructure, suppressions de données. Les opérations à haut risque. Comment pratiquer : après chaque migration significative, écrivez une réflexion d'un paragraphe. Le patron entre migrations est votre entraînement.
Choisissez la compétence qui correspond à votre déception d'infrastructure la plus récente. Pratiquez-la pendant un mois.
En quoi ce rôle diffère de l'ingénieur de données hérité
| Ingénieur de données hérité (avant l'IA) | Ingénieur de données (IA-natif) |
|---|---|
| Temps substantiel à écrire pipelines, ETL et requêtes d'entrepôt à la main | Le code de pipeline est largement absorbé par l'agent ; le temps va à l'architecture et à la conception |
| L'infrastructure de données est seulement interne : pour les analystes et les tableaux de bord | L'infrastructure de données sert maintenant les agents, les analystes, les utilisateurs internes et les produits externes |
| La discipline de coût est un nettoyage occasionnel | La discipline de coût est continue ; l'infrastructure d'IA introduit de nouvelles caractéristiques de coût |
| Les décisions de schéma sont surtout locales | Les décisions de schéma tiennent compte des consommateurs agents, des choix de modèles d'embeddings, de l'indexation vectorielle |
| L'observabilité est une réflexion après coup | L'observabilité est conçue dès le départ ; les mauvaises données attrapées à la source, pas au consommateur |
| Les meilleurs ingénieurs sont les plus rigoureux opérationnellement | Les meilleurs ingénieurs sont les architectes les plus nets, avec du jugement sur le coût et la fiabilité |
| Trajectoire : Ingénieur de données → Sénior → Lead → Director of Data | Trajectoire : la même, plus le mouvement latéral vers architecte de flux, superviseur d'agents (pour focus infrastructure d'IA), Senior FSE avec profondeur d'infrastructure |
Le rôle n'est pas un ingénieur de données plus rapide. C'est un rôle plus architectural : l'implémentation de pipeline s'absorbe, le jugement de conception s'étend.
Quels patrons d'évolution des rôles sont à l'œuvre
- Élévation (principal). Le centre de gravité du rôle s'élève de l'implémentation vers l'architecture, la conception de coût et la spécification d'observabilité.
- Convergence (secondaire). Les frontières avec le DevOps (infrastructure d'IA), l'ingénieur applicatif (fonctionnalités sensibles aux données) et l'analyste de données (définitions, instrumentation) s'estompent à mesure que le rôle d'ingénierie de données a du temps pour un partenariat transversal substantiel.
- Émergence (partiel). L'infrastructure d'IA (magasins vectoriels, pipelines d'embeddings, livraison de contexte aux agents) est une responsabilité véritablement nouvelle dans la portée de l'ingénieur de données.
La spécialisation à l'intérieur de l'ingénierie s'applique (le rôle reste distinct du Senior FSE parce que la matière est différente : flux de données vs interactions utilisateur, modes de défaillance silencieux vs bogues visibles, consommateurs d'infrastructure vs expériences face au client). Le patron de convergence au Niveau 3 dissout les frontières de spécialité intra-applicatives (FE/BE) plus qu'il ne dissout la frontière applicatif-vs-infrastructure-données, qui reste opérationnellement distincte.
Rôles liés dans le catalogue
l'équivalent en ingénierie applicative ; les deux livrent par spécifications et jugement, mais la matière diffère
partenaire sur l'infrastructure qui soutient les systèmes de données
consommateur principal ; partenaire sur les définitions et l'instrumentation
Sources et lectures complémentaires
- Patel, N. (2026). From Tasks to Roles: How Agentic AI Reconfigures Occupational Structures.
- Dans ce cadre : Ingénierie de la fiabilité, Standards d'exécution IA et L'organisation IA-native.
← Retour aux rôles · L'organisation IA-native · Patrons d'évolution des rôles · Cadre de référence · Ingénierie de la fiabilité