Le data scientist devient-il un manager IA ?

Le data scientist devient surtout un chef d’orchestre IA. Il construit moins de modèles from scratch, il déploie, supervise et gouverne des systèmes LLM, RAG et agents. Le vrai sujet maintenant, c’est la production fiable, les garde-fous, le monitoring et la capacité à expliquer ce qui tourne.

Pourquoi le métier change si vite ?

Le métier change parce que la valeur se déplace de la construction de modèles vers leur intégration en production. Avant, on valorisait beaucoup la capacité à entraîner un modèle propre, à comparer des scores, à optimiser une prédiction. C’est toujours utile, bien sûr. Mais aujourd’hui, l’entreprise veut surtout savoir si l’IA fonctionne dans un vrai workflow business, avec des utilisateurs, des données imparfaites, des droits d’accès, des erreurs possibles et des impacts réels.

Les données de marché citées par LinkedIn et Lightcast vont dans ce sens. Les compétences qui montent le plus tournent autour des LLM, les grands modèles de langage comme GPT, du RAG, une méthode qui connecte un modèle à des documents ou bases internes, du prompt engineering, donc l’art de cadrer correctement les demandes faites à l’IA, du MLOps, qui consiste à déployer, surveiller et maintenir des modèles, et de la gouvernance IA, c’est-à-dire les règles, contrôles et responsabilités autour des systèmes IA.

Dit simplement, les entreprises ne cherchent plus seulement quelqu’un qui sait entraîner un modèle. Elles cherchent quelqu’un qui sait faire tenir un système IA dans la vraie vie.

• Est-ce que les données sont fiables et à jour ?
• Est-ce que l’IA a le droit d’accéder à cette information ?
• Est-ce qu’on peut tracer ce qu’elle fait ?
• Est-ce qu’on peut mesurer ses erreurs ?
• Est-ce qu’on peut l’arrêter si elle dérive ?

L’IA générative automatise aussi une partie des tâches analytiques de base. Faire une première analyse, résumer un fichier, générer du code SQL, produire un graphique, proposer une segmentation client… Tout ça va plus vite. Du coup, le data scientist glisse vers des missions plus proches de l’architecture, du contrôle qualité et de la supervision.

Et oui, le salaire suit. Pas par magie. Il suit parce que le risque monte. Une IA en production, connectée aux données internes, aux outils métier, parfois même aux clients, peut créer de la valeur très vite. Elle peut aussi faire des dégâts très vite.

J’ai vu ça chez plusieurs clients. Le blocage n’est presque jamais le modèle en lui-même. Le vrai sujet, c’est l’intégration, la qualité des données, les droits d’accès, les tests, les logs, et la capacité à prouver que le système fait bien ce qu’on attend. Quand on passe de modèles isolés à des agents qui travaillent ensemble, le rôle devient clairement un rôle d’orchestration.

Que veut dire orchestrer des agents IA ?

Orchestrer des agents IA, c’est découper le travail entre plusieurs agents, contrôler leurs échanges et éviter qu’une erreur se propage partout. Ce n’est pas juste “mettre plusieurs prompts ensemble”. C’est penser un système où chaque agent a un rôle clair, des limites, des règles de décision et des points d’arrêt.

Un système multi-agents, avec des outils comme LangGraph, CrewAI ou AutoGen, permet de faire travailler plusieurs agents spécialisés. LangGraph aide à représenter les étapes et les boucles comme un graphe. CrewAI pousse plutôt l’idée d’équipes d’agents avec des rôles. AutoGen facilite les échanges entre agents. Mais le sujet n’est pas l’outil. Le vrai sujet, c’est le design du système.

Dans un cas data assez classique, je peux avoir plusieurs agents qui se répartissent le travail :

• Un agent ingère les données depuis un CRM, un fichier ou une base SQL.
• Un agent prépare les variables, détecte les valeurs manquantes et propose des transformations.
• Un agent évalue la qualité d’une sortie, par exemple avec des métriques ou des tests métier.
• Un agent produit un reporting clair pour une équipe métier.

Le data scientist ne code donc plus seulement un modèle isolé. Il conçoit un système distribué. Il sépare les responsabilités, il prévoit des boucles de rétroaction, il fixe des limites de retries, c’est-à-dire le nombre de tentatives autorisées quand une étape échoue, et il place des points d’arrêt. Ces points d’arrêt sont essentiels. Un agent trop autonome peut produire une réponse très plausible, bien formulée, mais fausse. Et si personne ne bloque cette erreur, elle peut contaminer tout le workflow.

Le passage en production change aussi la donne. Plus il y a d’agents, plus il faut penser logs, auditabilité, supervision, seuils d’alerte et reprise sur erreur. Les logs servent à comprendre ce qui s’est passé. L’auditabilité permet de retracer une décision. La supervision permet de voir si le système dérive ou se bloque. Dans les projets IA, je préfère un workflow moins spectaculaire mais contrôlable, plutôt qu’une démo brillante impossible à maintenir trois semaines après.

Avant	Après
Modèle isolé	Système avec plusieurs agents spécialisés
Pipeline classique	Workflow agentique avec décisions intermédiaires
Exécution linéaire	Boucles de rétroaction, retries et points d’arrêt
Suivi ponctuel	Supervision continue, logs, alertes et auditabilité

Pourquoi les agents ont besoin de supervision ?

Les agents IA donnent vite l’impression qu’ils peuvent tout faire seuls. Je le vois souvent chez des clients : une démo marche très bien, puis dès qu’on branche l’agent à de vraies données, à de vrais droits d’accès et à de vraies règles métier, ça devient moins magique.

Le sujet, c’est que les agents restent imprévisibles. Ils peuvent prendre une bonne initiative, puis faire un détour inutile, mal interpréter une consigne, inventer une information ou appliquer une règle dans le mauvais contexte. Et quand ils tournent sans cadre, c’est très dur de comprendre après coup pourquoi ils ont pris telle décision.

C’est là qu’on voit le fameux production gap. Beaucoup d’entreprises testent des agents IA, mais elles peinent à passer à l’échelle. Pas parce que le modèle est nul. Souvent, le problème vient d’ailleurs : les données ne sont pas propres, les règles métier sont implicites, les accès sont mal définis, et la traçabilité n’est pas suffisante. En clair, l’agent est prêt à agir, mais l’environnement autour de lui ne l’est pas.

Un workflow agentique structuré sert justement à éviter ça. On ne laisse pas forcément l’agent décider de tout. On définit son périmètre, ses outils, ses points de contrôle, et les moments où un humain doit valider. Un agent peut préparer, classer, résumer, proposer. Mais certaines actions doivent rester sous validation, surtout quand elles ont un impact client, financier, juridique ou opérationnel.

Cas d’usage	Niveau de supervision
Préparer un reporting interne	Autonomie assez forte, avec contrôle qualité régulier
Envoyer une recommandation client	Validation humaine avant envoi
Modifier une donnée critique dans un CRM ou un ERP	Supervision stricte, journalisation complète

L’arbitrage est délicat. Trop de supervision, et on tue les gains de productivité. Trop peu, et on augmente le risque d’erreur, d’hallucination ou de décision non conforme. Et ça, ce n’est pas totalement automatisable. Il faut comprendre le business, les données, les risques, et surtout le coût réel d’une erreur.

C’est pour ça que le rôle du data scientist évolue. Il ne construit plus seulement un modèle ou un pipeline. Il aide à définir où l’agent peut agir seul, où il doit demander confirmation, et comment on prouve que le système reste fiable. Et superviser ne suffit pas. Il faut aussi mesurer en continu la qualité des sorties, sinon on pilote à l’aveugle.

Comment évaluer une IA en production ?

Évaluer une IA en production, c’est surveiller ses performances, ses dérives, ses erreurs et la qualité de ses réponses dans le temps. Un modèle n’est pas une pièce magique qu’on livre une fois pour toutes, c’est un composant vivant dans un système avec des données, des utilisateurs, des règles métier, des coûts et des incidents possibles.

Le monitoring, c’est la surveillance continue. Je regarde si le modèle répond encore correctement, s’il met trop de temps, s’il coûte trop cher, s’il se trompe sur certains cas. La dérive, elle, arrive quand le monde change autour du modèle. Les données d’entrée ne ressemblent plus aux données d’entraînement. Les usages changent. Les clients posent des questions différentes. Et là, même un bon modèle peut devenir moyen sans prévenir.

Il faut donc prévoir des cycles de retraining, c’est-à-dire réentraîner ou ajuster le modèle quand les performances baissent. Il faut aussi des tests réguliers, avec des batteries d’évaluation. Une batterie d’évaluation, c’est un ensemble de cas connus, simples, difficiles, limites, parfois volontairement piégeux, qu’on rejoue pour vérifier que le système tient encore la route.

Le prompt engineering fait partie de ce travail qualité. Un prompt, ce n’est pas juste une phrase bien écrite. C’est une interface entre le modèle, les données et le résultat attendu. Je dois gérer le contexte fourni au modèle, réduire les hallucinations, tester plusieurs formulations, prévoir les cas limites, écrire des consignes système claires et poser des garde-fous. Une hallucination, c’est quand l’IA invente une réponse crédible mais fausse. C’est exactement le genre de problème qui passe bien en démo et très mal en production.

Avec les LLM, les grands modèles de langage, et le RAG, la génération augmentée par récupération, le sujet devient encore plus concret. Si le système récupère de mauvaises informations dans la base documentaire, même un très bon modèle peut produire une mauvaise réponse. Je surveille donc la donnée source, la récupération du bon contexte, la génération et la sortie finale. Dans mes missions, je regarde autant les erreurs silencieuses que les erreurs visibles, parce que les erreurs silencieuses sont celles qui coûtent cher.

Élément à monitorer	Ce que je vérifie
Qualité des données	Données fraîches, complètes, fiables et cohérentes.
Pertinence du contexte	Documents récupérés utiles, à jour et liés à la demande.
Taux d’erreur	Réponses fausses, incomplètes ou hors sujet.
Hallucinations	Informations inventées ou non vérifiables.
Latence	Temps de réponse acceptable pour l’usage réel.
Coût	Consommation API, tokens, infrastructure et maintenance.
Validation humaine	Contrôle des cas sensibles et retours terrain exploitables.

Quelles compétences deviennent vraiment utiles ?

Ce qui devient vraiment utile, ce n’est pas juste de savoir créer un modèle performant dans un notebook. C’est de savoir le mettre dans un vrai environnement, avec des utilisateurs, des risques, des coûts, des bugs, des règles métier et des gens qui vont demander “Pourquoi l’IA a répondu ça ?”.

Les compétences qui prennent de la valeur sont celles qui permettent de déployer, superviser, sécuriser et expliquer des systèmes IA. Un LLM, c’est un grand modèle de langage comme GPT ou Claude. Le RAG, c’est une méthode qui connecte ce modèle à vos propres documents pour éviter qu’il invente trop. Le prompt engineering, c’est l’art de formuler les consignes pour obtenir un comportement fiable. Le MLOps, c’est tout ce qui permet de passer d’un modèle expérimental à un système suivi, versionné, testé et maintenable.

Dans les entreprises, j’observe souvent le même basculement. Savoir entraîner un modèle reste utile, bien sûr. Mais ce n’est plus toujours là que se crée le plus de valeur. Le vrai sujet, c’est souvent : Comment je branche cette IA à mon CRM, à mon outil support, à mon entrepôt de données, à mes règles de validation, à mon reporting ?

• LLM et RAG pour construire des assistants utiles sur des données internes.
• Garde-fous et gouvernance pour limiter les erreurs, les fuites de données et les usages non conformes.
• Monitoring pour suivre la qualité, les coûts, les temps de réponse et les dérives.
• Orchestration d’agents pour faire travailler plusieurs briques IA dans un workflow cohérent.
• Reporting pour expliquer ce qui se passe aux métiers, à la direction et parfois aux équipes conformité.

Le nouveau profil fort, c’est un profil hybride. Il garde une compréhension statistique solide, une vraie culture data, mais il ajoute du sens produit, de la qualité logicielle, une vision d’architecture de workflow et une capacité à parler simplement aux métiers.

La compétence clé, à mon avis, c’est de savoir rendre compte. Dire ce que fait le système. Pourquoi il l’a fait. Où sont les risques. Comment on le corrige. Un client m’a déjà dit un truc très juste : “Je ne veux pas une IA magique, je veux une IA que je peux défendre en comité.” Voilà le niveau attendu.

Côté employabilité, c’est assez direct. Les offres et les salaires favorisent ceux qui savent passer du prototype à la production. Un notebook impressionnant ne suffit pas si personne ne peut maintenir, auditer ou brancher le résultat à un processus réel.

Le data scientist qui progresse aujourd’hui, c’est celui qui devient fiable dans l’exécution, pas seulement brillant dans l’expérimentation.

Et si la vraie valeur était dans la supervision ?

Le data scientist ne disparaît pas, il change de centre de gravité. La construction de modèles reste importante, mais la valeur se joue de plus en plus dans l’orchestration des agents, le RAG, les prompts, le MLOps, les garde-fous et le monitoring. C’est moins glamour qu’une démo IA qui bluffe tout le monde, mais c’est ce qui permet de tenir en production. Pour moi, le bon profil data maintenant, c’est quelqu’un qui comprend les modèles, mais qui sait surtout les faire tourner proprement dans un vrai contexte business. Le bénéfice pour vous est simple : moins de prototypes inutiles, plus d’IA fiable et exploitable.

FAQ

• Le data scientist va-t-il arrêter de créer des modèles ?
  Pas complètement. La création de modèles reste utile, mais elle devient moins centrale dans beaucoup d’entreprises. La demande se déplace vers l’intégration de LLM, le RAG, les workflows agentiques, le monitoring et la gouvernance. Le sujet n’est plus seulement de créer un bon modèle, c’est de le faire tourner correctement en production.
• Pourquoi parle-t-on de manager IA pour les data scientists ?
  Parce que le rôle ressemble de plus en plus à de la supervision de systèmes IA. Le data scientist orchestre des agents, définit les règles, contrôle les erreurs, met des garde-fous et surveille les performances. Il ne manage pas forcément des humains, il manage des systèmes automatisés qui prennent une place réelle dans les workflows business.
• Quelles compétences IA sont les plus recherchées ?
  Les compétences qui ressortent fortement sont les LLM, le RAG, le prompt engineering, le MLOps, la gouvernance IA, le monitoring, les garde-fous et l’orchestration d’agents. Les données de marché citées par LinkedIn et Lightcast vont dans ce sens : les entreprises cherchent des profils capables de produire de la valeur avec l’IA en conditions réelles.
• Pourquoi les agents IA ne peuvent-ils pas être laissés seuls ?
  Parce qu’ils peuvent être imprévisibles, inefficaces ou difficiles à auditer. Un agent peut produire une réponse plausible mais incorrecte, utiliser un mauvais contexte ou propager une erreur à d’autres agents. C’est pour ça qu’on met des checkpoints, des validations humaines et des limites claires dans les workflows.
• Le prompt engineering est-il une vraie compétence technique ?
  Oui, quand il est traité sérieusement. Ce n’est pas juste écrire une bonne consigne. Il faut gérer le contexte, réduire les hallucinations, tester les cas limites, mesurer la qualité des réponses et maintenir les prompts dans le temps. Dans un système IA en production, le prompt fait partie de l’ingénierie qualité.

 

 

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, analytics engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. J’accompagne des équipes data, marketing et digitales sur des sujets très concrets : fiabiliser les données, automatiser les workflows, connecter l’IA aux outils métier et mettre en place des systèmes mesurables. J’ai travaillé avec des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige aussi l’agence webAnalyste et l’organisme Formations Analytics. Si vous voulez structurer vos projets IA ou data, contactez-moi.