Comment clarifier les rôles pour mieux exploiter la data science

Une équipe peut construire un modèle d’attrition précis, une prédiction des clients qui partiront, et pourtant laisser l’équipe customer success prendre exactement les mêmes décisions. Pour un dirigeant qui évalue l’investissement, la question est de savoir si la prédiction parvient à quelqu’un qui peut agir à temps et assumer la responsabilité du résultat. La qualité du modèle compte dans ce workflow, mais l’organisation doit aussi définir comment le résultat modifiera une décision.

Commencez par la décision et la capacité qu’elle exige

Pour établir ce lien, partez de la décision que l’organisation entend prendre et de la manière dont elle réagira à la réponse. Un workflow responsable définit la question, les données d’appui, la personne responsable et l’action qui s’ensuit. Choisir Databricks ou Snowflake ne règle guère ces questions. Compréhension métier, compétence technique, rigueur en ingénierie logicielle, méthodes statistiques et connaissance fonctionnelle agissent de concert lorsqu’une personne assume la décision qu’elles soutiennent.

Partir de la décision permet aussi de clarifier la capacité analytique qu’elle exige. La business intelligence organise les données en rapports et mesures pour les décisions métier ; la data science utilise des méthodes statistiques et computationnelles pour étudier des questions et élaborer des prédictions ou des recommandations. Le machine learning, ou ML, développe des modèles qui apprennent des schémas à partir des données, tandis que le machine learning en production rend ces modèles disponibles dans des workflows opérationnels en direct. Déterminez quelle capacité la décision exige avant d’engager des effectifs et un budget sur une méthode avancée.

Quatre catégories analytiques aident les équipes à faire ce choix. Chacune répond à une question différente, et progresser vers la prédiction et l’action recommandée ajoute des exigences en matière de preuves, d’entrées fiables et d’intégration opérationnelle. Ensemble, elles fournissent un test de préparation : une équipe qui revendique une capacité doit pouvoir expliquer comment les personnes utiliseront son résultat.

Un examen hypothétique de l’onboarding montre comment le travail descriptif prépare la question pour l’analyse diagnostique. Le constat descriptif est : « L’activation a baissé de 8 % après le changement d’onboarding. » L’explication diagnostique identifie ensuite où enquêter : « La baisse se concentre sur les tenants de l’UE sur mobile après l’ajout d’une étape de vérification supplémentaire. » Le pourcentage mesure la perte, tandis que le segment des tenants de l’Union européenne, l’usage mobile et le changement de vérification resserrent le champ des interventions possibles.

Une fois qu’une équipe comprend le schéma actuel, le travail prédictif s’interroge sur un événement futur. La demande hypothétique, « Quels comptes vont churner dans les 30 prochains jours afin que le CS puisse intervenir ? », définit à la fois une fenêtre de prédiction et un utilisateur visé : le customer success, abrégé en CS. La réponse doit parvenir à cette équipe tant qu’une intervention reste possible ; produire des scores de comptes exige donc un processus de livraison maintenable autant qu’un modèle.

Le travail prescriptif transforme la prédiction en décision avec contraintes. L’exemple, « Proposer la remise X au segment Y dans les limites de marge, sinon orienter vers le playbook de rétention Z », précise une recommandation, une limite financière et une procédure de repli. Pour le livrer, un processus clairement attribué doit exécuter la recommandation et surveiller ce qui suit. Une remise proposée dans une analyse a encore besoin d’un dispositif opérationnel avant que l’organisation puisse l’appliquer de manière responsable.

Ces exigences aident les dirigeants à choisir un niveau d’ambition approprié. Les discussions sur l’intelligence artificielle, ou IA, et sur des méthodes avancées telles que les réseaux de neurones, des modèles construits à partir d’unités computationnelles connectées, et le deep learning, qui utilise de nombreuses couches de ces unités, peuvent prendre de l’avance alors que les mesures de base restent contestées. Un tableau de bord descriptif peut répondre pleinement au besoin métier, tandis qu’un système prédictif peut nécessiter un travail opérationnel important avant de pouvoir répondre au sien. Le test de préparation consiste à savoir si la méthode choisie peut soutenir la décision visée.

Tester l’usage opérationnel et la fiabilité des entrées

La capacité choisie a besoin de deux fondations : les personnes doivent utiliser son résultat, et les entrées doivent rester fiables. Ces exigences sont distinctes, car un modèle intégré peut agir sur des données peu fiables, tandis qu’un dataset bien maintenu peut soutenir une analyse que personne n’utilise. Examiner les deux donne aux dirigeants un diagnostic plus clair que l’inspection de notebooks, de présentations ou des dépenses de plateforme. Cela permet aussi de distinguer des entrées peu fiables, une ingénierie de déploiement manquante, une capacité scientifique insuffisante et des systèmes sans propriétaire, chacun appelant une réponse différente.

Le résultat change-t-il le travail ?

Commencez l’examen opérationnel en demandant ce que les personnes font différemment après avoir reçu le résultat. Les comptes peuvent faire l’objet d’un routage différent, les évaluateurs de fraude peuvent traiter une file plus vite, les analystes métier peuvent modifier leurs recommandations, ou les équipes customer success peuvent prendre des mesures de rétention différentes. Un deck, un notebook, un tableau de bord ou une investigation prend de la valeur grâce à ce lien avec le travail. Par exemple, un tableau de bord utilisé dans une revue métier hebdomadaire obligatoire peut soutenir un workflow descriptif complet parce que ses destinataires ont une décision récurrente à prendre.

Le lien devient plus facile à examiner lorsque l’équipe nomme le propriétaire de la décision, le lieu d’utilisation et l’action suivante. Le timing relève de la même spécification, car un résultat peut être disponible tout en arrivant après la décision qu’il était censé soutenir. Un évaluateur doit pouvoir identifier directement chaque condition opérationnelle.

Ces conditions exigent un accord avec les équipes censées utiliser le travail. Le Produit, les Opérations ou l’Ingénierie peuvent être incapables d’adopter une analyse terminée si personne n’en a défini le propriétaire, le lieu de livraison ou le timing. L’investissement a alors financé l’exploration sans organiser l’usage opérationnel. D’autres itérations de modélisation peuvent améliorer l’analyse tout en laissant l’adoption inchangée.

L’écart entre le développement du modèle et son exploitation apparaît dans l’enquête 2024-2025 sur le ML et le MLOps de DataTalks.Club. Le MLOps désigne les pratiques d’ingénierie utilisées pour déployer et exploiter des systèmes de machine learning. Près de quatre répondants sur dix ont indiqué qu’ils ne déployaient pas de modèles, tandis que plus de la moitié ont déclaré n’assurer aucun monitoring des modèles en production. Les réponses décrivent deux écarts opérationnels différents : rendre les modèles disponibles et observer leur comportement après leur mise en service.

Ces écarts nécessitent des questions d’examen distinctes, car le déploiement et le monitoring servent des objectifs différents. Le déploiement rend une prédiction disponible pour un workflow, tandis que le monitoring aide l’équipe à détecter un comportement peu fiable. Une équipe peut mener une analyse exploratoire, créer des modèles statistiques et générer des prédictions tout en manquant de l’une ou l’autre de ces conditions. Son activité technique doit donc être examinée en parallèle de ses dispositifs opérationnels.

Une règle de mise en production peut rendre ces dispositifs concrets. Exigez que chaque initiative formule sa décision, son propriétaire et son lieu d’utilisation en une phrase, que ce lieu soit un système de customer relationship management, ou CRM, une file d’opérations, un processus de planification ou un workflow produit. Si l’équipe ne peut pas écrire cette phrase, suspendez la mise en production jusqu’à ce que le dispositif soit clair. La règle instaure une obligation de livraison qui peut être vérifiée avant la publication d’un nouvel artefact.

L’organisation peut-elle faire confiance à ses entrées ?

Une fois qu’un résultat entre dans un workflow, les défaillances des entrées peuvent affecter de vraies décisions. Prenons le cas d’un indicateur métier qui change le vendredi mais n’attire l’attention que le lundi. Une partie de la défaillance tient au fait qu’aucune personne ni aucun processus n’est responsable de détecter ce changement et d’y répondre. Le nettoyage des données peut traiter le symptôme immédiat, mais la direction doit aussi attribuer la responsabilité de la détection et de la réponse.

Attribuer cette responsabilité exige de regarder en amont du modèle. Les défaillances peuvent apparaître lors de la collecte, de l’ingestion (le transfert des données dans un système), du traitement, du stockage ou de la définition des métriques. Une prédiction peut être calculée correctement alors même que la signification ou le contenu du dataset a changé. Demander aux data scientists de réparer chaque symptôme en aval laisse le problème de fiabilité en amont intact et consomme du temps destiné au travail analytique.

Les définitions des métriques relèvent de cette investigation, car les équipes peuvent interpréter différemment le même enregistrement. Un client, une commande, un utilisateur actif ou une conversion peuvent avoir des sens différents selon les fonctions. Tant que ces différences ne sont pas résolues, les parties prenantes peuvent tirer des conclusions incohérentes du même résultat de modèle. Des entrées fiables exigent donc des définitions responsables autant qu’un traitement fiable.

La responsabilité doit couvrir l’ensemble du parcours, des données source jusqu’aux tables reconnues comme faisant autorité. Les équipes ont besoin de propriétaires pour les standards de collecte, les règles de traitement, les définitions des métriques, le monitoring de l’ingestion, la gouvernance du stockage, la réponse aux incidents et ces datasets de référence. Les propriétaires doivent aussi gérer les changements de schéma : des modifications de champs, de types de données ou de structure qui peuvent altérer le comportement en aval. Ces responsabilités rendent explicite le lien entre les événements enregistrés et les résultats rapportés.

Lorsque ce parcours échoue, l’organisation a besoin d’une réponse opérationnelle comparable à un incident applicatif. Un flux d’événements rompu, un changement de schéma inattendu, un job d’ingestion en échec ou un dataset corrompu doivent déclencher une réponse définie, comme le ferait une panne d’infrastructure. Les dirigeants doivent savoir qui reçoit l’appel lorsqu’un dataset devient peu fiable. Sans intervenant désigné, l’organisation accepte un risque en aval dont personne n’est chargé de limiter les effets.

Le risque augmente à mesure que davantage de systèmes dépendent des mêmes données. Une petite défaillance peut se propager à travers des rapports, des tableaux de bord, des prévisions et des systèmes de production avant que les équipes concernées ne s’en aperçoivent. L’extension vers le machine learning, la modélisation prédictive, la business analytics et l’intelligence artificielle ajoute des décisions qui dépendent de ces entrées. La fiabilité des données a donc besoin d’une attention opérationnelle continue, au même titre que la fiabilité applicative.

L’enquête de Gartner menée auprès de 782 responsables infrastructure et opérations, réalisée fin 2025, illustre les enjeux pour les projets d’IA. Dans cette enquête, 38 % ont identifié la mauvaise qualité des données ou la disponibilité limitée des données comme une cause directe d’échec des projets d’IA. Le constat couvre à la fois l’état des données disponibles et l’accès aux données requises. L’un ou l’autre problème peut empêcher une initiative de soutenir la décision visée.

Le constat de Gartner éclaire l’examen des entrées, tandis que les résultats de DataTalks.Club éclairent l’examen du déploiement et du monitoring. Les enquêtes portent sur des groupes de répondants différents et traitent d’exigences opérationnelles différentes. Les dirigeants peuvent utiliser chacune d’elles pour formuler des questions distinctes sur l’initiative : les entrées sont-elles exploitables, le résultat atteint-il un workflow, et son comportement est-il supervisé ?

Précisez le travail de data science et ses responsables avant d’incriminer les talents

Une fois que l’examen identifie une condition manquante, les dirigeants peuvent définir le travail nécessaire pour la résoudre. Une initiative peut stagner parce que personne n’est responsable de la signification des données, de l’intégration ou du résultat opérationnel visé. Dans ce contexte, la plainte hypothétique « il nous faut de meilleurs data scientists » détourne l’attention des décisions que l’organisation doit encore prendre. Même un data scientist plus compétent a besoin d’un problème défini, d’un calendrier d’action et de contraintes.

Définir ces conditions peut demander plus d’efforts que construire le modèle, car les parties prenantes doivent s’accorder sur la manière dont leurs processus vont changer. Elles doivent harmoniser les définitions, répartir les responsabilités et établir la livraison attendue. Les projets prédictifs et prescriptifs doivent donc préciser trois prérequis avant de poursuivre de nouvelles itérations de modélisation.

Une fois la livraison définie, le staffing peut suivre le travail. Une expansion guidée par des termes à la mode peut pousser des analystes vers des missions de machine learning ou occuper des data scientists avec des opérations de données de base. Les organisations dont les fondations data sont faibles ou dont la responsabilité est floue sont particulièrement mal servies par cette approche. La question de conception des rôles est de savoir ce que chaque personne doit livrer pour modifier la décision spécifiée.

Répondre à cette question permet de distinguer des fonctions souvent regroupées. Chacune apporte une partie différente du processus opérationnel, tandis que le propriétaire métier ou produit reste responsable du résultat. Les frontières ci-dessous aident les dirigeants à attribuer le travail et à évaluer si un rôle manque ou s’il manque simplement de capacité.

L’exemple précédent sur l’attrition met en évidence un manque de staffing si le data scientist ne bénéficie d’aucun support en ingénierie du machine learning : le livrable peut s’arrêter à un notebook et à une transmission. À l’inverse, demander à des data engineers de « faire de la data science » peut produire des systèmes fiables avec peu d’influence sur les décisions. Les data scientists combinent méthodes statistiques, données quantitatives et historiques, et expertise métier pour élaborer des recommandations, tandis que les ingénieurs fournissent l’infrastructure nécessaire pour les utiliser à grande échelle. Attendre d’un seul recrutement technique qu’il absorbe toutes ces responsabilités rend le travail manquant plus difficile à voir.

Les examens de staffing doivent donc tester les responsabilités à l’aide de questions concrètes. Qui maintient les tables source faisant autorité et leurs SLA, et qui aligne les parties prenantes sur les définitions des métriques ? Qui gère le cycle de vie du modèle, y compris le monitoring, le réentraînement avec des données mises à jour et le retour à un état antérieur fiable ? Les dirigeants doivent aussi établir qui est responsable des résultats des décisions et de la cohérence des données métier entre les équipes, car des réponses claires aident à distinguer une véritable pénurie de capacité d’un problème de conception des rôles.

La gouvernance rend les décisions importantes responsables

La responsabilité devient particulièrement importante lorsque les recommandations affectent les clients, les approbations, la tarification, l’examen des fraudes ou l’allocation des ressources. La détection de fraude, la modélisation de l’attrition et la business analytics pour la planification opérationnelle exigent toutes que l’organisation autorise le système, supervise son usage et intervienne lorsque les résultats deviennent peu fiables. Ces obligations découlent des décisions influencées. La méthode de modélisation ne détermine pas qui a l’autorité d’agir.

Pour exercer cette autorité, la direction doit savoir qui approuve le modèle, qui est responsable de ses résultats, qui surveille ses performances et qui peut le désactiver. Le monitoring doit couvrir la dérive des données, c’est-à-dire les changements dans les schémas d’entrée ; la dérive de concept, c’est-à-dire les changements dans la relation entre les entrées et le résultat prédit ; et l’écart entre entraînement et service, c’est-à-dire les différences entre les conditions d’entraînement et les entrées ou traitements en production. Chacun de ces phénomènes peut réduire la fiabilité après le déploiement ; le plan de monitoring doit donc préciser comment l’équipe le détectera et y répondra.

Le monitoring technique a aussi besoin d’une revue métier, car un modèle qui fonctionne peut malgré tout produire des décisions inacceptables. Quelqu’un doit évaluer l’impact métier et, le cas échéant, l’équité et l’exposition réglementaire. Ces responsabilités restent nécessaires que l’équipe utilise le deep learning, les réseaux de neurones, des modèles statistiques ou une autre approche de machine learning. Choisir une famille de modèles laisse encore à attribuer l’autorité d’intervention et la responsabilité en cas de préjudice.

Les contrôles doivent correspondre aux conséquences de la décision. Les usages à fort impact exigent un niveau approprié d’examen en matière d’équité, de confidentialité et de réglementation, tandis que tout modèle opérationnel a besoin d’un propriétaire responsable et d’une voie de reprise. Un dispositif minimal de gouvernance rend explicites les responsabilités suivantes.

Une autorité explicite peut aussi accélérer le travail, car les équipes savent qui décide et qui intervient. Un prototype a encore besoin de responsables pour le monitoring, la reprise et les résultats avant de satisfaire aux exigences du machine learning opérationnel. Ces attributions comptent lors d’un incident, d’une recommandation contestée ou d’une décision d’arrêter d’utiliser le système. La gouvernance donne à l’équipe la permission et la responsabilité de réagir lorsque les conditions changent.

Les mêmes obligations s’étendent à l’IA générative, ou GenAI, qui produit du contenu, et aux systèmes agentiques, qui exécutent des séquences d’actions. Un chatbot, un copilot ou un workflow autonome a besoin d’entrées fiables, d’un propriétaire explicite, de monitoring et d’un moyen d’inverser ou d’arrêter un fonctionnement peu fiable. Une démonstration sans propriétaire se heurte au problème d’adoption décrit plus haut pour les modèles prédictifs. La nouvelle technologie exige toujours que l’organisation définisse qui peut agir et qui peut intervenir.

Choisir une structure d’équipe au service de l’efficacité décisionnelle

Une fois les responsabilités clarifiées, la structure organisationnelle doit aider les personnes à les assumer de manière cohérente. Débattre d’abord des lignes hiérarchiques peut laisser sans réponse la question du propriétaire de la décision et des frontières entre rôles. Les dirigeants devraient plutôt se demander si l’organisation aide les data scientists, les analystes, les machine learning engineers et les data engineers à améliorer les décisions dans toute l’entreprise. Trois structures courantes offrent des avantages et des risques différents.

Le principal arbitrage porte sur la manière dont les pratiques partagées restent connectées au contexte décisionnel local. Une fonction centralisée peut recevoir ce contexte trop tard ou de manière incomplète, ce qui complique l’adoption. Les équipes intégrées travaillent plus près des besoins métier, mais leur indépendance peut les conduire à répéter le travail ou à développer des définitions incohérentes. La structure doit traiter le risque le plus susceptible de perturber le workflow visé.

Les dispositifs hybrides relient des standards centraux à une application locale. La fonction centrale fixe les attentes en matière de qualité des données, de modèles, d’expérimentation, de revue des modèles, de visualisation et de gouvernance. Les data scientists travaillant aux côtés des équipes métier aident les personnes à analyser les résultats, à en interpréter le sens et à les appliquer à des processus spécifiques. De nombreuses organisations adoptent ce dispositif, mais son efficacité dépend d’une répartition claire des responsabilités entre les fonctions centrales et intégrées.

Choisir entre ces structures exige d’évaluer les exigences réglementaires, les obligations de gouvernance des données, les possibilités de réutiliser le travail et la maturité organisationnelle. Les capacités de plateforme existantes, la disponibilité des machine learning engineers et les besoins de support en production déterminent aussi si une structure peut soutenir les décisions visées. Une organisation hiérarchique adaptée a encore besoin de personnes ayant le temps de faire le travail. Cela fait de la capacité d’exécution une partie distincte de l’examen.

Une stratégie claire exige malgré tout une capacité d’exécution suffisante

La capacité peut limiter la livraison même lorsque l’organisation comprend la décision, possède les données et sait comment le déploiement doit fonctionner. Les équipes peuvent voir des opportunités d’améliorer les entrées, de renforcer les prévisions pour la planification ou de fournir un support décisionnel prédictif tout en manquant de temps pour agir. Le travail entre en concurrence avec la livraison de la roadmap, la modernisation de la plateforme, les programmes de sécurité, les fonctionnalités orientées client et le support opérationnel. Une responsabilité claire aide à répartir ce travail, mais elle ne crée pas d’heures d’ingénierie supplémentaires.

L’effet métier dépend de la fonction qui est contrainte. Une demande générale de personnel supplémentaire en data science peut passer à côté du véritable problème de livraison. Les dirigeants doivent identifier le travail manquant et le relier à l’échéance que l’entreprise doit respecter.

Deux profils d’entreprise illustratifs montrent pourquoi la capacité doit être évaluée par fonction. Une entreprise peut disposer d’analystes expérimentés et d’une forte connaissance métier, mais de trop peu de machine learning engineers pour déployer des systèmes prédictifs. Une autre peut employer des data scientists compétents tout en manquant du travail de plateforme nécessaire à des fondations data fiables. Chacune a besoin d’une capacité adaptée à la fonction manquante plutôt que d’un jugement sur la compétence de son équipe existante.

Des spécialistes externes constituent un moyen de compléter la capacité interne lorsque le travail de support à la décision entre en concurrence avec d’autres engagements. BairesDev commercialise cette approche dans Data Science: How to Evaluate Teams and Outcomes et a un intérêt commercial à ce que les organisations achètent une extension d’équipe. Son offre fournit des ingénieurs seniors d’Amérique latine, ou LATAM, pour la data science, l’ingénierie du machine learning et l’ingénierie data au sein des processus de livraison, workflows opérationnels et organisations d’ingénierie déjà établis chez les clients. BairesDev présente ce dispositif comme un moyen d’accélérer l’exécution tout en préservant la connaissance institutionnelle et la responsabilité interne.

La pertinence de cette offre dépend du diagnostic de capacité. Recrutement, support externe, réorganisation et amélioration du modèle répondent à des situations différentes ; les dirigeants doivent donc choisir le remède après avoir identifié la contrainte. Le test de capacité consiste à savoir si l’organisation peut livrer dans le délai exigé par l’entreprise. Un plan qui pourrait finir par réussir peut malgré tout manquer la fenêtre de décision qui donne sa valeur au travail.

Lier l’approbation de l’investissement à une condition de livraison

Cette échéance peut devenir une condition explicite de l’approbation de l’investissement. La demande de financement doit nommer la condition de livraison manquante et expliquer comment la dépense la résoudra. L’approbation établit une exigence d’évaluation plutôt qu’un calendrier de mise en œuvre universel, car la gouvernance, le travail sur les données, l’intégration et le staffing doivent souvent progresser ensemble.

La demande doit aussi préciser comment les résultats seront mesurés après le déploiement, afin de donner au propriétaire métier un moyen de juger si le système livré aide réellement. Des réponses positives aux tests de préparation augmentent la probabilité de créer de la valeur, mais le retour des décisions réelles doit montrer si les résultats s’améliorent et si le système reste pertinent.

Une demande de financement doit rendre le changement proposé suffisamment concret pour être évalué. L’ingénierie de déploiement peut être évaluée par rapport à un workflow attribué en attente d’intégration en production, tandis que l’ingénierie data peut l’être par rapport à des obligations de fiabilité spécifiées. Chaque demande doit nommer la décision qui en bénéficie et la condition de livraison qu’elle modifiera. Si ce lien reste indéfini, financez le travail nécessaire pour l’établir avant d’ajouter davantage de modélisation.

En résumé

Évaluer une équipe de data science commence par la décision qu’elle est censée améliorer. La précision du modèle, l’expertise technique et les capacités de la plateforme comptent, mais elles n’établissent pas si le travail parvient à une personne responsable à temps pour influencer un résultat. Les dirigeants doivent examiner ce lien avant de décider d’agrandir l’équipe, d’en changer la structure ou d’investir dans un autre modèle.

Le prochain investissement doit traiter la condition qui bloque la livraison. Des entrées peu fiables appellent une responsabilité sur les données et de l’ingénierie. Un modèle bloqué dans un notebook a besoin d’un chemin vers la production et d’un support opérationnel. Une recommandation inutilisée exige un accord sur qui agira, quand et dans quelles contraintes. Traiter ces points comme des problèmes distincts rend les décisions de staffing et de financement plus précises.

Avant d’approuver un nouvel investissement, exigez une description claire de la décision, de son propriétaire, du workflow qui utilisera le résultat et de la mesure du succès. Déterminez ensuite qui supervisera les performances et interviendra si le système devient peu fiable. Ces engagements donnent aux dirigeants une base pour évaluer à la fois la livraison et les résultats métier.

L’ambition appropriée est la capacité analytique que l’entreprise peut utiliser de manière responsable. Un tableau de bord fiable peut mieux soutenir une décision qu’un modèle prédictif sans propriétaire ni processus de livraison. Construisez la capacité qu’exige la décision, financez le travail nécessaire pour la rendre exploitable et jugez sa valeur à l’aune des résultats qui suivent.