Data Scientist vers l'IA appliquée : quelles compétences transférer en priorité

Le point de départ n'est pas une page blanche

Une partie des contenus sur le sujet part du principe qu'un Data Scientist doit se réinventer entièrement. Ce n'est ni exact ni utile. Le métier existe, il continue d'exister, et rien n'oblige à en changer. Cet article s'adresse à celles et ceux qui souhaitent se rapprocher des rôles IA appliquée ou GenAI, et qui veulent savoir ce qui se transpose, ce qui manque, et vers quelle trajectoire s'orienter.

Le point important est qu'il n'existe pas une transition unique. « Aller vers l'IA » recouvre au moins trois directions très différentes, qui n'exigent pas les mêmes apprentissages et ne conduisent pas aux mêmes entretiens. Choisir la direction avant de choisir les apprentissages évite plusieurs mois perdus.

Ce qui se transpose, et qui est souvent sous-estimé

Les compétences suivantes ne sont pas des acquis secondaires : elles manquent fréquemment aux profils venus du développement logiciel, et elles sont difficiles à acquérir sur le tas.

• Raisonnement statistique : savoir qu'un écart observé peut n'être qu'un effet d'échantillon, et savoir estimer ce qui vaut la peine d'être conclu.
• Culture de l'expérimentation : formuler une hypothèse, définir la mesure avant de regarder le résultat, distinguer un effet d'une coïncidence.
• Compréhension des données : savoir d'où elles viennent, comment elles sont produites, ce qui manque, ce qui est biaisé, et pourquoi une colonne ne veut pas dire ce que son nom suggère.
• Conception de métriques : choisir ce qu'on mesure, voir ce qu'une métrique ne dit pas, et repérer les cas où optimiser la métrique dégrade le service.
• Validation : jeux de test propres, absence de fuite de données, comparaison à une référence simple, méfiance envers un résultat trop beau.
• Communication des résultats : expliquer une incertitude à une personne qui doit décider, sans la masquer ni la transformer en refus de conclure.
• Python, selon le profil : socle réel chez certains, plus limité chez d'autres — les notebooks et le code de production ne demandent pas les mêmes pratiques.

Sur les systèmes GenAI, ce socle a une valeur immédiate. La question centrale de ces projets — comment sait-on que ce système fonctionne, et sur quelles données l'affirme-t-on ? — est exactement une question d'évaluation. Beaucoup d'équipes construisent des systèmes convaincants en démonstration sans personne capable de la poser correctement.

Toutes ces compétences ne sont pas présentes chez tous les Data Scientists : les profils varient énormément selon les organisations, entre analyse, modélisation, ingénierie de données et travail proche du produit. La première étape consiste à faire cet inventaire honnêtement, sans se prêter le profil moyen d'une fiche de poste.

Les écarts possibles selon la trajectoire visée

Ce qui manque n'est pas le même selon la direction. Voici trois trajectoires courantes, décrites par ce qu'elles demandent en plus, pas par leur prestige supposé.

Vers ML Engineer

L'accent se déplace du résultat d'analyse vers le système qui tourne. Ce qui devient central : écrire du code destiné à être lu, testé et maintenu par d'autres ; exposer un modèle derrière une interface stable ; gérer les versions et les dépendances ; tenir des contraintes de performance et de coût ; savoir ce qui se passe quand le service tombe. La difficulté n'est presque jamais mathématique, elle est logicielle et opérationnelle.

Vers AI / GenAI Engineer

Le modèle est souvent externe, l'essentiel du travail se situe autour : construire une chaîne de récupération d'information, décider ce qui est fourni au modèle, encadrer les sorties, mesurer la qualité par séries de cas, instrumenter, arbitrer coût et latence. Le réflexe d'évaluation transfère directement ; ce qui manque relève surtout de l'ingénierie logicielle et de l'exploitation, plus la compréhension fine des comportements propres aux modèles génératifs.

Vers un rôle AI Product ou transverse

Ici, l'accent se déplace vers le cadrage : quel problème mérite d'être traité, ce qu'une solution à base de modèle peut et ne peut pas garantir, comment définir un niveau de qualité acceptable avec des utilisateurs, comment arbitrer entre valeur, risque et coût, et comment expliquer une limite à des personnes non techniques. La compétence de communication et de métriques y est un atout majeur ; ce qui manque relève de la conduite produit, de la relation avec les parties prenantes et de la décision en incertitude.

Ces trois trajectoires ne sont pas hiérarchisées. Elles correspondent à des goûts différents : construire des systèmes durables, résoudre des problèmes ouverts avec des modèles, ou décider de ce qu'il faut construire.

Une méthode en quatre temps

L'objectif est de sortir du « je devrais apprendre plein de choses » pour arriver à une trajectoire et une première preuve.

1. 1

   Inventorier ce que vous savez déjà faire

   étape 1

   Écrivez ce que vous avez réellement livré : quels problèmes, quelles données, quelles décisions, quels résultats, quelle part de code, quelle part de production. Distinguez ce que vous avez fait seul de ce que vous avez fait dans une équipe. Cet inventaire est aussi la matière première de votre CV et de votre pitch d'entretien.

2. 2

   Identifier les manques par rapport à une trajectoire, pas dans l'absolu

   étape 2

   Prenez plusieurs offres correspondant à la direction visée et relevez ce qui revient systématiquement. Séparez ce qui est réellement exigé de ce qui relève de la liste d'outils décorative. Vous obtenez en général deux ou trois manques structurants, pas quinze.

3. 3

   Choisir une trajectoire cohérente avec ce que vous aimez faire

   étape 3

   Système, problème ouvert, ou décision produit. Un critère utile : sur vos projets passés, quelle partie vous a le plus intéressé, et laquelle vous avez subie ? Une transition tenue sur la durée se choisit sur ce critère plutôt que sur l'intitulé le plus visible du moment.

4. 4

   Construire une seule preuve, défendable en profondeur

   étape 4

   Un cas réel, de préférence dans votre contexte professionnel actuel : un système d'aide à la recherche interne, une évaluation d'un outil existant, l'industrialisation d'un modèle qui tournait en notebook. Une preuve que vous pouvez décrire en détail — problème, contraintes, décisions, ce qui a échoué — vaut mieux que trois projets de démonstration standards.

Le chemin le plus court passe souvent par l'employeur actuel

La transition la plus solide se fait fréquemment sans changer d'entreprise. Vous connaissez déjà les données, les utilisateurs et les contraintes, ce qui est précisément ce qui manque à un candidat externe. Prendre en charge la partie évaluation d'un projet GenAI existant, ou l'industrialisation d'un modèle resté à l'état de prototype, produit une expérience réelle plutôt qu'un projet personnel.

Cette étape intermédiaire a un autre intérêt : elle vous dit si la trajectoire vous convient avant que vous n'y engagiez une recherche d'emploi. Certaines personnes découvrent à ce moment qu'elles préfèrent rester sur des problèmes d'analyse et de modélisation, et cette conclusion est un résultat, pas un échec.

Comment présenter la transition sans se dévaloriser

Deux erreurs symétriques. La première consiste à se présenter comme débutant, en effaçant une expérience qui a de la valeur. La seconde consiste à revendiquer une expérience de production qu'on n'a pas, ce qui se détecte à la deuxième question technique.

La formulation qui fonctionne relie l'existant à la cible : ce que vous savez faire depuis des années, ce que vous avez construit récemment dans la direction visée, et ce que vous êtes en train d'acquérir. Nommer ce qui vous manque encore, avec la manière dont vous le comblez, est reçu comme un signe de lucidité — bien plus que comme une faiblesse.

• Trajectoire
• Évaluation
• AI Engineering