Le data scientist devient-il manager d’IA en entreprise ?

Le data scientist pilote de plus en plus des systèmes d’IA plutôt qu’il ne construit des modèles à la main. Le vrai sujet, c’est l’orchestration, la supervision, les tests, la gouvernance et l’intégration fiable dans les workflows business.

Pourquoi le rôle change si vite ?

Le rôle change vite parce que la valeur n’est plus juste dans “j’ai entraîné un modèle”. Ça, c’était déjà difficile. Mais aujourd’hui, le vrai sujet c’est plutôt : est-ce que ce modèle fonctionne dans un process réel, avec des données imparfaites, des utilisateurs pressés, des règles métier, des risques, et quelqu’un qui doit assumer la décision derrière ?

Les tâches classiques du data scientist ne disparaissent pas, mais elles prennent moins de place. Le SQL, le nettoyage de données, les graphiques simples, les analyses exploratoires… Une partie est déjà accélérée par des assistants IA, des outils BI plus intelligents, ou des plateformes low code. On gagne du temps sur l’exécution. Du coup, on attend autre chose du data scientist.

Avant	Maintenant
Construire un modèle from scratch	Choisir quoi automatiser, quoi surveiller, quoi garder humain
Faire des dashboards	Intégrer l’IA dans un workflow métier
Nettoyer les données à la main	Mettre en place des contrôles qualité fiables
Optimiser une métrique technique	Assumer l’impact business et les risques

Les signaux marché vont dans le même sens. LinkedIn identifie en 2025 la littératie IA, donc la capacité à comprendre et utiliser l’IA correctement, et la maîtrise des LLM comme des compétences en forte croissance. Un LLM, c’est un grand modèle de langage, comme ceux utilisés dans ChatGPT ou Claude. Lightcast indique aussi que 51 % des offres liées à l’IA sont hors des rôles IT traditionnels. Ça veut dire que l’IA sort du labo tech. Elle arrive dans les RH, la finance, le juridique, le marketing, les opérations.

Et le marché paie cette bascule. Les compétences IA sont associées à une prime salariale autour de 56 %. Aux États-Unis, les offres qui demandent ces compétences peuvent payer environ 18 000 dollars de plus par an. Ce n’est pas juste une mode LinkedIn. C’est une vraie revalorisation du rôle.

Les compétences qui montent sont très concrètes. Le prompt engineering, c’est savoir formuler et cadrer les demandes faites à un modèle. Le RAG, pour Retrieval Augmented Generation, consiste à connecter un LLM à vos propres documents pour qu’il réponde avec votre contexte. Le MLOps, c’est l’ensemble des pratiques pour déployer, surveiller et maintenir des modèles en production. Les workflows de gouvernance servent à définir qui valide, qui contrôle, qui intervient quand l’IA se trompe.

Chez mes clients, le problème n’est presque jamais de tester un LLM une fois. Ça, tout le monde y arrive en deux heures. Le vrai sujet, c’est de l’intégrer proprement dans un process qui tient dans le temps, avec des seuils, des logs, des validations humaines, et une donnée assez propre pour éviter de fabriquer n’importe quoi à grande vitesse.

Que change l’arrivée des agents IA ?

Je vois un vrai basculement avec les agents IA. On ne parle plus juste d’un modèle qui répond à une question. On parle d’un système qui découpe, délègue, vérifie, recommence, et parfois prend une décision ou prépare une action.

Les frameworks comme LangGraph, CrewAI ou AutoGen montrent bien ce changement. Ils permettent d’organiser plusieurs agents dans un workflow, c’est-à-dire une chaîne de travail structurée. Un agent cherche l’information, un autre la résume, un autre vérifie la cohérence, un autre prépare une réponse ou déclenche une action. Le data scientist devient moins “celui qui entraîne un modèle” et plus “celui qui conçoit le système autour du modèle”.

Ce n’est pas un détail. Gartner indique que les demandes liées aux systèmes multi-agents ont augmenté de 1 445 % entre le premier trimestre 2024 et le deuxième trimestre 2025. Et Gartner projette aussi que des agents seront intégrés dans 40 % des applications d’entreprise d’ici fin 2026, contre moins de 5 % en 2025. Ça va très vite, peut-être même trop vite pour certaines organisations.

Le nouveau travail devient très concret. Il faut découper une tâche complexe en sous-tâches exécutables, décider quel agent fait quoi, définir les entrées et les sorties attendues, prévoir les erreurs possibles, poser des garde-fous, créer des boucles de rétroaction. Une boucle de rétroaction, c’est simple : le système observe le résultat, le compare à ce qui était attendu, puis corrige ou demande une validation.

Le vrai sujet, c’est la contamination de la chaîne. Imaginez un agent qui extrait un mauvais montant depuis un contrat. Un deuxième agent reprend ce montant pour calculer une marge. Un troisième prépare un reporting. À la fin, quelqu’un prend une décision sur une donnée fausse. Et tout avait l’air propre.

Pour éviter ça, je place les contrôles à plusieurs endroits :

• Validation humaine quand l’impact métier est fort.
• Règles métiers pour bloquer les valeurs impossibles ou incohérentes.
• Logs pour garder la trace de ce que chaque agent a fait.
• Alertes quand une sortie sort du comportement attendu.
• Seuils de confiance pour forcer une revue quand le système n’est pas assez sûr.

Plus on donne d’autonomie à un agent, plus il faut penser architecture, limites et responsabilité. C’est là que le data scientist change vraiment de posture.

Ancien rôle	Nouveau rôle
Construire un modèle	Orchestrer des agents
Produire une analyse	Surveiller une chaîne IA
Corriger une donnée	Concevoir un garde-fou

Comment superviser l’IA en production ?

Superviser l’IA en production, ce n’est pas regarder un dashboard de temps en temps. C’est décider où l’IA a le droit d’agir seule, où elle doit être contrôlée, et où un humain garde la main.

Au début, beaucoup d’équipes ont testé des agents très autonomes. Un agent, c’est un système IA capable d’utiliser des outils, d’enchaîner des actions et de prendre des décisions intermédiaires. Sur le papier, c’est séduisant. Dans la vraie vie, ça devient vite compliqué. L’agent part dans une direction inattendue, consomme trop d’appels API, produit une réponse difficile à expliquer, ou modifie une donnée sans qu’on sache vraiment pourquoi.

C’est pour ça que les entreprises reviennent vers des workflows agentiques structurés. Un workflow agentique, c’est toujours de l’IA qui agit, mais dans un cadre clair. Avec des étapes définies, des règles conditionnelles, des points de contrôle, et du human-in-the-loop, donc une validation humaine quand le risque le justifie.

McKinsey observe en avril 2026 un vrai déplacement des rôles vers la supervision et l’orchestration. Près des deux tiers des entreprises ont expérimenté des agents, mais peu ont réussi à passer à l’échelle. Et 80 % citent les limitations de données comme principal obstacle. Ça ne m’étonne pas. Quand j’aide une équipe à passer du prototype IA à la prod, la discussion devient vite moins glamour mais beaucoup plus utile : logs, responsabilités, validation, rollback, qualité de données.

Le data scientist doit alors trancher des sujets très concrets :

• Quelles actions doivent être loggées, avec l’entrée, la sortie, le modèle utilisé et la version du prompt.
• Quelles réponses peuvent être revues en batch, par exemple chaque jour ou chaque semaine.
• Quelles décisions exigent une approbation synchrone, avant exécution.
• Quels seuils déclenchent une alerte, comme un score de confiance faible ou une donnée manquante.
• Quelles erreurs sont tolérables, et lesquelles doivent bloquer le workflow immédiatement.

Le rapport MIT Sloan / BCG 2025 résume bien le piège. Trop de supervision annule les gains. Trop peu de supervision crée des risques de conformité, de sécurité et de réputation. Le bon niveau dépend du métier, du coût de l’erreur et de la capacité à revenir en arrière.

Je vois la supervision comme une surface produit. Ce n’est pas un détail technique caché dans un backlog. C’est l’interface entre l’IA, l’équipe métier et le risque. Si cette interface est floue, personne ne sait qui décide. Si elle est bien conçue, l’IA devient beaucoup plus simple à déployer, à auditer et à améliorer.

Pourquoi les prompts deviennent des actifs ?

Je vois souvent la même erreur en entreprise : on traite le prompt comme une petite phrase qu’on peut bricoler vite fait. En réalité, dès qu’il pilote une réponse client, une analyse métier ou une décision opérationnelle, le prompt devient un actif. Il influence le comportement du système. Il doit donc être testé, versionné et surveillé comme du code.

Le prompt engineering, ce n’est pas juste écrire “réponds comme un expert”. C’est gérer la fenêtre de contexte, c’est-à-dire la quantité d’informations que le modèle peut prendre en compte. C’est aussi faire du grounding, donc ancrer la réponse dans des sources fiables, souvent via du RAG, la méthode qui permet au modèle d’aller chercher des documents avant de répondre. Et c’est surtout réduire les hallucinations, tester les cas limites, vérifier que les réponses restent stables dans le temps.

Ce n’est pas un sujet marginal. Les postes liés au prompt engineering ont progressé de 135,8 % en 2025. Ce chiffre dit quelque chose de simple : les entreprises comprennent que le modèle n’est pas magique. Il est un composant dans un système plus large.

Un prompt de démonstration impressionne en réunion. Il marche sur trois exemples propres, avec des données bien rangées. Un prompt de production, lui, doit tenir quand les données sont incomplètes, quand l’utilisateur pose une question ambiguë, quand le contexte change, quand le modèle refuse à tort ou répond hors format. J’ai vu un client perdre confiance dans un assistant interne juste parce qu’une nouvelle version du prompt avait baissé la précision sur des cas très fréquents. Rien de spectaculaire. Juste assez pour casser l’usage.

Les contrôles à mettre en place sont assez concrets :

• Des jeux de tests avec des cas normaux, ambigus et limites.
• Des échantillons de réponses validées par des experts métier.
• Des comparaisons entre versions de prompts avant mise en production.
• Une surveillance des refus, hallucinations, réponses hors format et baisses de précision.
• Des moniteurs de dérive pour détecter quand les entrées ou les réponses changent trop.

C’est là que le MLOps se spécialise. L’objectif reste simple : repérer quand le système cesse d’être fiable avant que les utilisateurs ou les clients ne le subissent. Parfois, il faut ajuster le prompt. Parfois, changer le contexte RAG. Parfois, réentraîner ou remplacer le modèle.

Élément	Ce qu’il faut gouverner
Prompt	Version, tests, stabilité, cas limites.
Contexte RAG	Sources, fraîcheur, pertinence, citations.
Données	Qualité, complétude, biais, changements.
Modèle	Version, performance, coût, comportement.
Logs	Entrées, sorties, erreurs, refus.
Métriques	Précision, hallucinations, format, latence.
Validation humaine	Contrôle métier, arbitrage, retours terrain.
Seuils d’alerte	Détection des régressions et déclenchement d’actions.

Quelles compétences garder en priorité ?

Je garderais les fondamentaux data. Pas par nostalgie, mais parce que c’est encore là que beaucoup de projets IA se gagnent ou se plantent. Comprendre une donnée, savoir d’où elle vient, ce qu’elle représente, ce qu’elle oublie, quels biais elle porte, ça reste central. La différence, c’est qu’on ne l’utilise plus seulement pour entraîner un modèle. On l’utilise pour alimenter un LLM, construire un RAG, superviser un agent, mesurer la qualité d’une réponse ou automatiser un processus métier.

Un LLM, c’est un grand modèle de langage. Il prédit du texte avec une capacité impressionnante, mais il ne “sait” pas si votre base client est propre, si votre procédure interne est à jour, ou si une réponse est acceptable juridiquement. Le RAG, pour Retrieval Augmented Generation, consiste à brancher le modèle sur vos propres documents et données pour produire des réponses plus fiables. Là, le data scientist a un vrai rôle. Pas juste faire une démo. Faire un système qui tient.

Les compétences à renforcer tournent autour de quelques blocs très concrets :

• Comprendre les LLM : Savoir ce qu’ils font bien, ce qu’ils inventent, et pourquoi ils peuvent se tromper avec beaucoup d’assurance.
• Maîtriser le prompt engineering : Pas écrire des phrases magiques, mais structurer une demande, un contexte, des contraintes et des exemples.
• Concevoir une architecture RAG : Choisir les bonnes sources, découper les documents, indexer, retrouver la bonne information et tester la qualité.
• Orchestrer des agents : Un agent IA enchaîne des actions, appelle des outils, prend des décisions intermédiaires. C’est puissant, mais ça demande des garde-fous.
• Évaluer en continu : Définir des métriques, tester les sorties, détecter les dérives, suivre les erreurs. Sans ça, on pilote au ressenti.
• Industrialiser avec du MLOps : Le MLOps, c’est l’ensemble des pratiques pour déployer, surveiller et maintenir les modèles en production.
• Travailler avec les métiers : Comprendre les vrais irritants, les validations nécessaires, les risques et les règles opérationnelles.

Je vois beaucoup d’équipes avec des démos IA très impressionnantes. Puis ça bloque. Les données ne sont pas fiables, personne ne sait valider les réponses, la supervision est floue, l’intégration dans les outils métier prend trois mois, et la conformité arrive trop tard dans la discussion. C’est précisément là que le data scientist peut reprendre une place stratégique. Pas en codant le modèle le plus complexe, mais en transformant un prototype sympa en système exploitable.

Compétence	Utilité concrète	Risque si elle manque
Compréhension des données	Identifier les sources fiables, les biais et les trous dans la donnée.	Le système répond bien en apparence, mais sur de mauvaises bases.
Architecture RAG	Connecter l’IA aux connaissances internes utiles.	Le LLM hallucine ou cite des informations obsolètes.
Évaluation continue	Mesurer la qualité, les erreurs, la stabilité et les dérives.	Personne ne sait si l’IA s’améliore ou se dégrade.
MLOps et monitoring	Déployer, surveiller et maintenir le système dans la durée.	La démo marche, mais la production devient ingérable.
Gouvernance et risque	Encadrer les usages, les accès, la conformité et les validations.	Le projet est bloqué par la sécurité, le juridique ou le métier.
Compréhension métier	Relier l’IA à un vrai processus et à une décision utile.	L’outil est techniquement bon, mais personne ne l’utilise.

Alors, c’est quoi le prochain cap ?

Le data scientist ne disparaît pas, il change de centre de gravité. Construire un modèle reste utile, mais ce n’est plus là que se joue toute la valeur. Le sujet, maintenant, c’est d’orchestrer des agents, superviser les sorties, tester les prompts, surveiller les dérives, gouverner les workflows et décider où l’humain doit rester dans la boucle. Les entreprises ont besoin de profils capables de relier la technique, la donnée et le risque business. Si vous êtes data scientist, c’est plutôt une bonne nouvelle : vous pouvez devenir la personne qui rend l’IA vraiment exploitable, pas juste impressionnante en démo.

FAQ

• Le data scientist va-t-il encore construire des modèles ?
  Oui, mais ce ne sera plus toujours son activité principale. Une partie de la valeur se déplace vers l’intégration, la supervision, l’évaluation et la gouvernance des systèmes IA déjà disponibles, notamment les LLM, les agents et les workflows RAG.
• Pourquoi parle-t-on de data scientist manager d’IA ?
  Parce que le rôle ressemble de plus en plus à de l’orchestration. Il faut coordonner des modèles, des agents, des données, des règles métier, des validations humaines et des métriques de fiabilité. Le data scientist devient responsable du comportement du système, pas seulement de son score initial.
• Quelles compétences IA sont les plus demandées ?
  Les compétences qui montent sont la maîtrise des LLM, le prompt engineering, l’intégration RAG, le MLOps, l’orchestration d’agents et la gouvernance. Les offres liées à l’IA sortent aussi des équipes IT classiques, ce qui montre que ces compétences deviennent transverses.
• Pourquoi les agents IA sont difficiles à mettre en production ?
  Parce qu’un agent autonome peut être imprévisible, difficile à auditer et sensible aux erreurs de données. Pour scaler, il faut des frontières claires, des logs, des checkpoints, des validations humaines et des règles sur ce que l’agent peut ou ne peut pas faire seul.
• Le prompt engineering est-il vraiment une compétence durable ?
  Le prompt isolé risque de devenir banal. Mais le prompt engineering sérieux, avec tests, versioning, grounding, surveillance des hallucinations et intégration dans un workflow de production, devient une vraie compétence d’ingénierie IA.

 

 

A propos de l’auteur

Je suis Franck Scandolera, responsable de l’agence webAnalyste et de l’organisme Formations Analytics. J’accompagne les entreprises sur le tracking avancé server-side, l’Analytics Engineering, l’automatisation No/Low Code avec n8n, l’intégration de l’IA, le SEO et le GEO. J’ai travaillé avec des équipes chez Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football, Texdecor et d’autres. Mon terrain, c’est justement ce passage entre prototype, data, automatisation et production fiable. Si vous voulez structurer vos projets IA sans partir dans tous les sens, contactez-moi.