Data scientist IA devient-il manager d’agents ?

Il devient surtout un manager de systèmes IA. Moins de modèles entraînés from scratch, plus d’agents, de RAG, de MLOps, de supervision et de gouvernance. Le vrai sujet maintenant, c’est de faire produire l’IA sans perdre le contrôle.

Pourquoi le métier bascule ?

Le métier bascule parce que la valeur n’est plus seulement dans le modèle qu’on construit from scratch. Elle est de plus en plus dans l’intégration, l’orchestration et la responsabilité des systèmes IA qui tournent vraiment en production.

Je le vois très clairement chez les clients. Avant, on attendait souvent du data scientist qu’il nettoie les données, teste des modèles, fasse des requêtes SQL, sorte des graphiques, explore les corrélations et présente un notebook propre. Ces tâches existent encore, bien sûr. Mais une partie est maintenant accélérée, voire partiellement automatisée, par l’IA générative.

Un LLM, c’est un grand modèle de langage, comme ceux derrière ChatGPT ou Claude. Il peut aider à écrire une requête SQL, proposer un nettoyage de données, générer une visualisation simple, résumer un dataset ou suggérer des pistes d’analyse exploratoire. Est-ce que c’est toujours juste ? Non. Est-ce que ça fait gagner du temps ? Oui, souvent beaucoup.

Ça ne rend pas le data scientist inutile. Ça déplace son centre de gravité. Le sujet n’est plus seulement “Quel modèle choisir ?”. Le sujet devient “Comment je branche ce modèle dans un workflow fiable, comment je contrôle ses sorties, comment je détecte les dérives, comment je documente les décisions, et qui assume quand ça part en production ?”.

Les signaux marché vont dans ce sens. LinkedIn 2025 et Lightcast pointent une demande forte autour de la culture IA, des LLM, du prompt engineering, du RAG, du MLOps et de la gouvernance. Le RAG, c’est le fait de connecter un modèle à vos propres documents pour lui donner du contexte fiable. Le MLOps, c’est l’ensemble des pratiques pour déployer, surveiller et maintenir des modèles en production. Rien de magique là-dedans. Le marché récompense surtout les compétences pratiques, pas les grands discours sur l’IA.

Le data scientist IA devient donc moins un artisan isolé du modèle, et plus un responsable de systèmes intelligents. C’est moins glamour sur le papier, parfois. Mais c’est là que la vraie valeur se crée.

Ancien rôle	Nouveau rôle
Construire un modèle dans un notebook	Intégrer un modèle dans un workflow métier
Produire des analyses ponctuelles	Surveiller des systèmes IA en continu
Optimiser une métrique technique	Gérer performance, risque et usage réel
Faire des requêtes et visualisations simples	Valider, contrôler et industrialiser les sorties
Livrer un prototype	Assumer ce qui part en production

Que change le multi-agent ?

Le multi-agent change surtout une chose : le data scientist IA ne construit plus seulement un modèle ou un prompt, il conçoit un système distribué. C’est un assemblage d’agents qui se parlent, se corrigent, appellent des outils, prennent des décisions limitées. On passe du “je fais répondre une IA” au “je pilote une chaîne de travail”. Et ça, franchement, ce n’est pas le même métier.

Un système multi-agent, c’est assez simple à comprendre. Plusieurs agents spécialisés collaborent. Chaque agent a une mission, un contexte, des outils accessibles et des limites. Un agent peut chercher l’information dans une base documentaire. Un autre peut vérifier les sources. Un autre rédige une synthèse. Un dernier déclenche une action dans un CRM, un ERP ou un outil ticketing. Le point clé, c’est que chaque agent ne fait pas tout. Il fait une partie du travail, avec un cadre clair.

Agent	Rôle typique en entreprise
Agent recherche	Récupère les données utiles dans les documents, bases internes ou API.
Agent contrôle	Vérifie la cohérence, les sources, les doublons, les règles métier.
Agent rédaction	Produit une réponse, un email, un compte rendu ou une recommandation.
Agent action	Crée un ticket, met à jour un outil métier ou déclenche un workflow.

Des frameworks comme LangGraph, CrewAI ou AutoGen servent justement à structurer ça. Pas besoin de leur attribuer des pouvoirs magiques. Ils aident à définir les rôles, organiser les échanges, gérer les boucles de feedback, placer des points de contrôle et ajouter des garde-fous. En gros, ils donnent une architecture au bazar potentiel.

Le signal marché est clair aussi. Gartner a signalé une très forte hausse des demandes autour des systèmes multi-agents entre le Q1 2024 et le Q2 2025. Et l’idée de fond, c’est que ces agents vont être de plus en plus intégrés dans les applications d’entreprise. Pas comme des démos isolées, mais dans les vrais outils du quotidien.

Le vrai sujet technique, il est là : une hallucination, une mauvaise donnée ou une hypothèse fausse au début peut contaminer toute la chaîne. J’ai vu ce problème chez un client sur un workflow de qualification commerciale. Le premier agent classait mal un besoin, et tous les agents suivants travaillaient proprement… sur une mauvaise base. Le rôle du data scientist devient donc de découper les tâches, poser les guardrails, prévoir les validations, limiter les effets domino et rendre le système auditable. Auditable, ça veut dire qu’on peut comprendre ce qui s’est passé, qui a décidé quoi, avec quelles données.

Avant de mettre un workflow multi-agent en production, je me pose toujours ces questions :

• Quelle tâche mérite vraiment plusieurs agents, et laquelle peut rester simple ?
• Où une erreur en amont peut-elle contaminer toute la chaîne ?
• Quels agents ont le droit d’agir dans un outil métier, et sous quelles limites ?
• Quels contrôles humains sont nécessaires avant une action sensible ?
• Quelles données chaque agent peut-il voir, modifier ou transmettre ?
• Comment tracer les décisions, les sources et les appels aux outils ?
• Que se passe-t-il si un agent bloque, hallucine ou répond hors cadre ?
• Quels indicateurs permettent de mesurer la qualité réelle du workflow ?

Comment garder le contrôle en production ?

On garde le contrôle en production avec des workflows agentiques structurés, des responsabilités claires, des logs utiles, des checkpoints humains et une supervision calibrée. Pas avec un agent “magique” à qui on donne les clés du système en espérant qu’il fasse les bons choix.

Les premiers agents autonomes ont montré leurs limites assez vite. Ils peuvent être impressionnants en démo, mais en production, l’autonomie totale expose vite le business. Un agent peut enchaîner des actions trop vite, appeler les mauvais outils, consommer beaucoup de ressources pour une tâche simple, ou prendre une décision difficile à expliquer après coup. Et quand personne ne sait exactement pourquoi une action a été lancée, l’audit devient pénible.

Les constats vont dans le même sens côté entreprises. McKinsey, en avril 2026, souligne que beaucoup d’organisations ont testé des agents IA, mais que peu arrivent à créer une vraie valeur à grande échelle. L’étude MIT Sloan avec BCG en 2025 va dans la même direction. Les pilotes existent, les promesses aussi, mais le passage à l’industrialisation reste dur. La qualité des données, leur accessibilité, les droits, les silos et les définitions métiers mal alignées restent des freins énormes.

C’est là que le data scientist IA change de rôle. Il ne fait pas juste un modèle ou un prompt. Il décide ce qui doit être tracé, ce qui doit être revu plus tard en batch, c’est-à-dire par lots après exécution, ce qui doit être validé en direct par un humain, et ce qui peut tourner sans validation. Il règle aussi le niveau d’oversight, donc le niveau de supervision. Trop de contrôle, et tout devient lent. Pas assez de contrôle, et le risque explose.

J’ai souvent vu des équipes vouloir automatiser trop vite. Avant même d’avoir clarifié la qualité des données, les droits d’accès ou qui est responsable si l’agent fait une erreur. Ça paraît moins excitant qu’un agent autonome, mais c’est exactement ce qui fait la différence entre une démo sympa et un système fiable.

Je découpe généralement la supervision en trois niveaux simples.

Niveau	Quand l’utiliser	Contrôle attendu
Automatique	Actions fréquentes, faibles risques, données fiables	Logs complets, alertes sur anomalies
Revue différée	Actions utiles mais sensibles, impact modéré	Contrôle en batch, échantillonnage, analyse des écarts
Validation humaine obligatoire	Décisions critiques, impact financier, juridique ou client	Approbation synchrone avant exécution

Quelles compétences valent vraiment ?

Les compétences qui valent vraiment, ce sont celles qui font fonctionner l’IA dans un contexte réel. Pas celles qui brillent en démo. Pas celles qui sortent un joli prototype sur trois documents propres. Celles qui tiennent quand il y a des données imparfaites, des utilisateurs pressés, du juridique dans la boucle, des coûts à surveiller et une direction qui veut savoir si ça marche vraiment.

Un data scientist IA doit comprendre les LLM, les grands modèles de langage, mais surtout leur environnement. Le prompt engineering n’est plus juste l’art d’écrire une belle consigne. C’est gérer le contexte, ancrer les réponses dans des sources fiables, réduire les hallucinations, tester plusieurs versions de prompts, comparer les résultats et surveiller les régressions. En 2025, les rôles liés au prompt engineering ont fortement augmenté, et ce n’est pas qu’une mode. Les entreprises ont compris qu’un prompt non testé, c’est du logiciel fragile déguisé en texte.

Le RAG devient aussi central. RAG veut dire Retrieval Augmented Generation, en gros un système qui va chercher des informations dans vos documents internes avant de répondre avec un modèle. Le vrai sujet, ce n’est pas juste de brancher une base documentaire. C’est de savoir quelles sources sont fiables, comment découper les documents, comment récupérer les bons passages, comment mesurer la pertinence, et comment prouver d’où vient la réponse. J’ai vu des projets RAG échouer non pas à cause du modèle, mais parce que la documentation interne était un bazar complet.

Le MLOps prend la même importance. C’est la discipline qui permet de gérer les modèles comme des composants vivants. On les surveille, on les teste, on les versionne, on compare leurs performances dans le temps. On regarde la dérive, c’est-à-dire le moment où les données réelles changent et où le modèle devient moins fiable. On met en place des suites de tests, du monitoring, des cycles de réentraînement si besoin.

La compétence rare n’est pas seulement technique. C’est la capacité à faire le pont entre data, produit, juridique, métiers et direction. Il faut savoir dire ce qui est fiable, ce qui ne l’est pas, ce qui peut être automatisé, et ce qui doit rester sous contrôle humain.

• 1. Comprendre les données métier pour savoir ce qui a du sens, ce qui manque, et ce qui peut casser en production.
• 2. Maîtriser le RAG pour connecter les modèles aux connaissances internes avec qualité, traçabilité et contrôle.
• 3. Industrialiser le prompt engineering avec tests, versions, mesures et suivi des régressions.
• 4. Monter en MLOps pour surveiller les modèles, gérer la dérive et organiser les réentraînements.
• 5. Savoir évaluer l’IA avec des critères clairs, pas juste avec une impression de bonne réponse.
• 6. Développer la gouvernance pour gérer les risques, les accès, les données sensibles et la responsabilité.
• 7. Faire le lien avec les décideurs pour transformer une capacité technique en usage fiable et utile.

Alors on se forme à quoi maintenant ?

Le data scientist IA ne disparaît pas, il change de rôle. Je le vois plutôt devenir celui qui rend l’IA exploitable, fiable et gouvernable. Construire un modèle reste utile, mais ce n’est plus le seul marqueur de valeur. Le vrai sujet, c’est de connecter des LLM à des données propres, d’orchestrer des agents, de tester les prompts, de surveiller les dérives et de poser les bons garde-fous. Ceux qui savent faire ça vont prendre de l’avance. Le bénéfice pour vous est simple. Vous transformez l’IA en système utile pour le business, pas en démo fragile.

FAQ

• Le data scientist IA doit-il encore savoir entraîner des modèles ?
  Oui, mais ce n’est plus suffisant. La compétence reste utile pour comprendre les limites des modèles, les biais, les métriques et les cycles de réentraînement. La valeur se déplace surtout vers l’intégration, l’évaluation, la supervision et la mise en production fiable.
• Pourquoi les agents IA changent-ils le rôle du data scientist ?
  Parce qu’un agent IA ne se contente pas de répondre. Il peut planifier, appeler des outils, transmettre une tâche à un autre agent et déclencher des actions. Le data scientist doit donc concevoir le système, poser les limites, surveiller les sorties et éviter qu’une erreur se propage dans toute la chaîne.
• Quelles compétences IA sont les plus utiles en entreprise ?
  Les compétences les plus utiles sont le prompt engineering industrialisé, le RAG, le MLOps, l’évaluation continue, la détection de dérive, la gouvernance et la connaissance des données métier. Ce sont celles qui permettent de passer d’une démo IA à un système réellement exploitable.
• Le prompt engineering est-il une vraie compétence technique ?
  Oui, quand il est traité sérieusement. Il ne s’agit pas juste d’écrire une consigne. Il faut gérer le contexte, tester les prompts, réduire les hallucinations, mesurer les régressions et documenter ce qui fonctionne. C’est une logique d’ingénierie, pas une astuce.
• Pourquoi la gouvernance devient-elle centrale avec l’IA ?
  Parce que les systèmes IA produisent des réponses, des décisions ou des actions qui peuvent impacter le business. Sans logs, sans responsabilités claires, sans validation humaine quand c’est nécessaire, on ne sait plus expliquer ni corriger ce qui se passe. La gouvernance permet de garder l’IA utile et maîtrisable.

 

 

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 produit sur des sujets très opérationnels, avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. Si vous voulez structurer vos usages IA, vos workflows data ou vos automatisations, contactez-moi.