Une équipe avec un expert ML qui ne touche à rien d'autre, un expert ingestion qui ne sait pas modéliser, un expert BI qui ne comprend pas les pipelines. Ça vous parle ? C'est le résultat de l'hyper-spécialisation. Et c'est un piège.
Chaque personne est un point unique de défaillance. La mobilité entre sujets est impossible. La frustration monte. Les dépendances se multiplient. Quelqu'un demande "je peux ajouter une feature ?" - l'expert ML dit oui, l'expert ML Ops dit qu'il faut changer l'infra, l'expert Feature Store a besoin d'une migration. Trois semaines pour une feature. Franchement, c'est intenable.
Le profil full-stack data : de quoi parle-t-on ?
Un profil full-stack data comprend la chaîne complète de valeur. Il peut écrire une requête SQL pour auditer les données brutes, un modèle dbt pour une transformation, du Python pour une analyse complexe, un modèle prédictif avec scikit-learn, exposer les résultats via une API, et monitorer le tout en production.
Il comprend les arbitrages de coûts - "cette agrégation supplémentaire en dbt coûte combien en crédits Snowflake ?" - et sait déboguer en production. Il parle aussi bien à un data engineer qu'à un expert ML qu'à un analyste métier.
Ce n'est pas un expert absolu dans chaque domaine. C'est quelqu'un de compétent partout, et c'est la polyvalence qui crée la valeur.
L'approche T-shaped : profondeur + largeur
Le T-shaped, c'est la bonne manière de penser la chose. Le vertical du T : une spécialité profonde. Le horizontal du T : des compétences dans tous les autres domaines.
Un analytics engineer spécialiste dbt - profond en modularité, versioning, testing - mais compétent en SQL, Python, analytique métier, bases du ML. Un data scientist expert en XGBoost et feature engineering - profond en ML - mais compétent en SQL, dbt, déploiement, infrastructure cloud.
La profondeur crée l'expertise. La largeur crée l'agilité. Sans la largeur, un expert dbt est bloqué dès que le besoin sort de son périmètre. Sans la profondeur, un "full-stack" superficiel n'est qu'un junior lent.
L'impact sur la productivité
L'équipe hyper-spécialisée face à une demande simple : trois personnes doivent se coordonner, trois calendriers à aligner, trois handoffs avec perte d'information. Résultat : trois semaines.
L'équipe T-shaped face à la même demande : deux personnes qui comprennent le sujet de bout en bout discutent, conçoivent ensemble, déploient en trois jours. La productivité est multipliée par trois. Les dépendances diminuent : personne n'attend que quelqu'un d'autre débloque.
Et les profils T-shaped sont plus satisfaits. Ils apprennent en continu, comprennent la chaîne de bout en bout, voient l'impact de leur travail en production. C'est un cercle vertueux.
Recruter le bon profil
Comment identifier un candidat T-shaped ? Regarder le portefeuille - a-t-il touché à plusieurs technologies ? Poser des questions ouvertes - "Décrivez un projet complet de A à Z." Évaluer la curiosité - "Qu'avez-vous appris récemment ?"
Les candidats T-shaped sont généralement des généralistes qui ont approfondi une spécialité. Pas des spécialistes qui élargissent lentement. La nuance est importante.
L'onboarding est aussi différent. Plutôt que "apprendre le ML", c'est "comprendre toute notre stack". Pair programming avec un data scientist, puis avec un data engineer, puis un petit projet end-to-end en autonomie. Le temps de montée en productivité est plus court. Et la rétention meilleure - les profils T-shaped voient la diversité du travail et s'ennuient moins.
L'évolution de carrière élargie
Dans une organisation hyper-spécialisée, la seule option est "expert ML" ou "expert infra". L'ennui arrive vite, la carrière est étroite. Avec des T-shaped, la progression se diversifie.
Un analytics engineer junior peut explorer sa spécialité dbt, mais aussi apprendre le ML, l'infra, ou le product management. Le chemin IC s'élargit : Junior, Mid, Senior, Staff, Principal en dbt - mais aussi des options latérales. "Staff Data Scientist avec expertise dbt", "Principal Engineer avec background analytics". C'est plus satisfaisant : on crée des carrières, pas des impasses.
La culture anti-silos
Les T-shaped créent une culture naturellement collaborative. Un data scientist qui sait aussi développer en Python comprend ce que demande la maintenance de ce code. Il écrit du code propre, compréhensible. Un analytics engineer qui comprend le ML sait qu'un calcul de feature prend du temps et propose des optimisations.
Les silos disparaissent. L'humilité augmente - personne n'est un "expert intouchable". Le respect croît parce que chacun apprécie la complexité de chaque domaine.
Chez Bomzai, chaque consultant est un entrepreneur de la data. T-shaped par conviction. C'est ce profil qu'on co-construit avec les équipes de nos clients : polyvalent, opérationnel, capable de mettre des cas d'usage en production de bout en bout. Parce que les résultats mesurables viennent des gens qui comprennent le système entier, pas de ceux qui n'en voient qu'un morceau.