Traducteur métier et donnée, le rôle qui manque aux projets IA

Un projet d'IA peut réunir des data scientists solides, une direction convaincue et un budget voté, puis s'arrêter au prototype. Le modèle fonctionne. Personne ne sait dire s'il répond au problème que le métier voulait régler ni qui doit le faire entrer dans le travail quotidien.

Thomas H. Davenport, professeur de technologies de l'information et de management au Babson College, a décrit avec Nitin Mittal, consultant en intelligence artificielle chez Deloitte, un rôle pensé pour cet endroit précis. Dans All-in on AI, paru en 2023, ils l'appellent le traducteur. Le passage tient en quelques lignes. Il pose pourtant une question que beaucoup d'organisations laissent sans réponse, celle de savoir qui habite l'espace entre ceux qui connaissent le métier et ceux qui connaissent la technique.

Qu'est-ce qu'un traducteur entre le métier et la donnée ?

Personne à l'aise avec les chiffres sans être data scientist, le traducteur fait le lien entre les responsables métier et les développeurs d'IA. Davenport et Mittal empruntent cette définition à DBS, la banque de Singapour qu'ils suivent de près dans leur livre. La banque a constitué un groupe de « translators » puis décidé d'affecter à ses projets d'IA un traducteur pour deux data scientists.

Sameer Gupta, alors directeur de l'analytique de DBS, décrit ce que la paire change. Quand les deux rôles collaborent, les data scientists peuvent se montrer plus expérimentaux dans leurs modèles pendant que le traducteur s'assure que le problème métier réel est bien celui qu'on traite. La liberté des uns repose sur la vigilance de l'autre.

Les auteurs ajoutent une remarque qui donne son titre à cet article. Le rôle, écrivent-ils, est assez largement discuté mais peu mis en place.

Ce que le rôle protège

Le livre ne détaille pas de fiche de poste. En croisant la définition de DBS avec ce que les auteurs écrivent ailleurs du déploiement et de la conduite du changement, le traducteur protège trois choses :

• La question de départ. Le problème métier est formulé dans des termes qu'un modèle peut traiter avant la première ligne de code.
• Le fil du projet. À chaque étape, quelqu'un vérifie que la réponse technique reste accrochée au besoin réel.
• L'arrivée dans le travail. Les futurs utilisateurs voient les prototypes, donnent leur avis et sont formés avant la mise en service.

Pourquoi les projets d'IA se perdent-ils entre le métier et la technique ?

Chaque rive attend que l'autre fasse la traversée. Davenport et Mittal observent que certains data scientists considèrent que leur travail s'arrête à un bon modèle ajusté aux données. Le déploiement passe alors pour le travail de quelqu'un d'autre, sans qu'on sache toujours de qui.

Or le déploiement change tout d'échelle. Un pilote consiste à construire un modèle et à coder un produit minimum viable. Une mise en production demande en plus de revoir des processus, de former les personnes et de raccorder le système aux outils existants. Dans l'enquête de Deloitte de 2018 que les auteurs citent, les trois premières difficultés citées sont la mise en œuvre, l'intégration de l'IA dans les rôles et les fonctions de l'entreprise puis les problèmes de données. Aucune des trois ne se règle dans le code.

Les chiffres qu'ils rassemblent datent d'avant la vague générative et ils sont sévères. Dans une enquête de 2019 de la MIT Sloan Management Review et du Boston Consulting Group, sept entreprises sur dix déclaraient un impact de l'IA minimal ou nul. En 2021, une enquête d'IBM auprès de plus de cinq mille décideurs technologiques trouvait 31 % d'entreprises ayant activement déployé l'IA dans leurs opérations.

Deux langages, deux intuitions

Un des exemples les plus parlants du livre ne vient pas d'une entreprise. Les auteurs ont interrogé les deux codirecteurs d'un centre de recherche créé au Broad Institute, à Cambridge dans le Massachusetts, grâce à une dotation de 250 millions de dollars destinée à croiser apprentissage automatique et biologie. À la question de ce qui pourrait faire échouer le projet, tous deux ont d'abord répondu la culture. Informaticiens et biologistes n'ont ni le même langage ni les mêmes intuitions face à un problème. Ils en étaient encore à explorer les parades, la principale consistant à organiser des rencontres entre les deux communautés.

Le chapitre consacré au facteur humain se clôt sur une idée voisine. La plupart des entreprises étudiées confirmeraient selon les auteurs que la technologie est la partie facile et que la difficulté consiste à mobiliser les personnes et l'organisation pour explorer, construire et utiliser l'IA.

Un projet d'IA se perd souvent à la frontière entre ceux qui connaissent le métier et ceux qui connaissent la technique. Quelqu'un doit habiter cette frontière.

Quel profil pour tenir le rôle de traducteur ?

Il faut une double compétence, assez quantitative pour comprendre ce que fait un modèle et assez ancrée dans le métier pour savoir ce qui compte. La définition de DBS le dit en creux, en écartant le data scientist. Le traducteur n'a pas à construire le modèle. Il doit savoir le questionner.

Je défends les profils en T, une base horizontale large et une vraie profondeur sur un domaine. Le traducteur en offre une déclinaison assez nette, la profondeur se trouvant ici dans le métier et la largeur dans la compréhension de la donnée.

Un profil qui existe souvent déjà dans la maison

Plusieurs entreprises du livre développent ces compétences en interne. DBS revendique plus de dix-huit mille employés formés aux compétences liées à la donnée. Environ deux mille d'entre eux ont atteint un niveau avancé. Airbus a formé plus d'un millier de personnes à la science des données et à l'analytique avec un dispositif qui engage aussi les managers. L'entreprise demande aux salariés comme à leurs managers d'y consacrer une demi-journée par semaine. Manager et salarié choisissent ensemble un projet pilote en science des données puis le manager en suit l'avancement.

Airbus y voit plusieurs bénéfices au-delà des compétences. Il s'est formé une communauté de personnes intéressées par la donnée avec laquelle l'équipe centrale peut travailler, tandis que les projets familiarisent les managers et leurs activités avec l'IA. Une telle communauté est un vivier naturel de traducteurs. Le constat rejoint une idée déjà défendue sur ce blog, l'expertise métier redevient un avantage décisif de la transformation IA.

Circuler plutôt que siéger

Le rôle demande moins une place qu'un mouvement. Le traducteur passe de la réunion métier à la revue de modèle, de la salle où l'on décide à celle où l'on construit. Le Host Leadership décrit un manager qui circule entre la scène, les invités, le balcon et la cuisine. La métaphore vaut assez bien pour le traducteur. Il s'avance quand le problème se déforme, se retire quand les équipes se comprennent sans lui.

Où placer le traducteur dans l'organisation ?

Dans le projet lui-même, dès son lancement. DBS affecte ses traducteurs aux projets d'IA. Les entreprises les plus avancées du livre prévoient le déploiement dès le départ, confient à une même personne tout le processus de développement et de déploiement puis font travailler data scientists et chefs de produit avec le métier dès le premier jour.

Cette personne porte parfois le titre de chef de produit pour les systèmes d'IA. Les auteurs expliquent sa présence par le moindre intérêt que data scientists et experts de l'IA portent souvent à la conduite du changement, comparée à la construction des modèles. La fonction rejoint celle que décrit l'article sur le Product Manager hybride qui garde la responsabilité business tout en prototypant avec l'IA. Traducteur et chef de produit se recouvrent en partie. Le premier garde la question métier, le second garde le chemin jusqu'à la production.

Scotiabank montre une autre façon de rapprocher les deux mondes. La fonction d'analytique et d'IA y est centralisée mais la plupart de ses data scientists sont rattachés directement aux différentes lignes métier. Ce sont les responsables de ces lignes qui fixent les cas d'usage à développer. Grace Lee, directrice de l'analytique de la banque jusqu'en octobre 2021, disait que les spécialistes de l'analytique et de l'IA ne se limitaient pas à un rôle de soutien et faisaient partie de la nouvelle ligne de front.

Le traducteur et la gouvernance de l'IA

Placé au cœur des projets, le traducteur voit tôt les questions qui relèvent de la gouvernance. Quelles données entrent dans l'outil ? Quelles décisions restent humaines ? Qui répond d'un résultat faux ? Ces questions trouvent leur cadre dans une charte d'usage de l'IA écrite pour l'entreprise elle-même. Le traducteur peut être le mieux placé pour signaler qu'un projet sort de ce cadre avant que le modèle ne soit construit.

Pourquoi préférer de petits projets qui aboutissent ?

Un modèle qui reste au stade du prototype ne produit aucune valeur économique. Les responsables de 84.51°, la filiale de données du distributeur américain Kroger, en ont fait le constat. Ils y ajoutent qu'un problème analytique mal posé peut faire plus de mal que de bien. Leur méthode, baptisée 8PML, s'ouvre donc sur une phase de cadrage de la solution où l'on formule l'analyse, précise les objectifs métier et les confronte aux ressources disponibles avant de modéliser. Ce cadrage est le terrain naturel du traducteur.

Le cadrage fait aussi apparaître très tôt la question des données. Un besoin métier bien formulé révèle vite si la donnée nécessaire existe, si elle est fiable et qui a le droit de s'en servir. Ce point décide souvent du sort d'un projet, tant la donnée reste le vrai goulot d'étranglement de l'IA en entreprise.

L'exemple de Scotiabank

Un dirigeant de Scotiabank, Phil Thomas, parle de « blue collar AI », une IA de col bleu. L'approche écarte la recherche et l'expérimentation pour retenir les projets qui ont de fortes chances de créer de la valeur dans un délai assez court. Pas de projet « big bang », seulement l'amélioration continue des opérations et de la relation client. D'après Grace Lee, 80 % des modèles d'analytique et d'IA de la banque étaient déjà déployés et 20 % en attente.

Davenport et Mittal présentent la banque comme la preuve qu'un démarrage tardif se rattrape, à condition de s'engager à investir dans la technologie et à en tirer parti. Le reste du livre défend l'engagement massif et durable des entreprises qui vont le plus loin. Les deux lectures se complètent. Une grande ambition se construit aussi à coups de projets modestes qui arrivent en production.

Apprendre de ce qui échoue

Les petits projets ne réussissent pas tous. Piyush Gupta, directeur général de DBS de 2009 à 2025, raconte que ses premiers essais ont échoué. En 2013, la banque a signé pour trois ans un laboratoire d'IA avec l'agence publique de recherche de Singapour. Une demi-douzaine de projets en sont sortis sans qu'aucun ne réussisse. Il les décrit comme des outils de signal pour l'organisation. Lui comme la banque en ont beaucoup appris. La banque s'est aussi donné pour indicateur de conduire mille expériences par an. Beaucoup portaient sur l'IA.

Un projet court dit vite ce qu'il vaut. C'est la logique d'une boucle de travail courte où la taille du lot décide de ce que l'équipe apprend. Le traducteur y tient la question métier d'un tour à l'autre.

Que devient ce rôle avec l'IA générative et les agents ?

Le livre ne peut pas répondre. Il a été bouclé avant l'arrivée publique des grands modèles de langage et l'enquête la plus récente qu'il cite date d'octobre 2021. Sa partie technique a vieilli. Sa partie sur les personnes, la culture et la formation tient mieux parce qu'elle décrit des organisations et non des machines.

Je travaille le sujet de l'IA en organisation depuis fin 2024. Dans plusieurs équipes que j'accompagne, les agents IA sont traités comme des équipiers, dotés d'un périmètre, de responsabilités et de limites et challengés en rétrospective comme les autres membres. Leur profil ressemble à celui d'un consultant. L'agent sait faire beaucoup de choses sans connaître entièrement le fonctionnel de la société ou de l'équipe.

Le périmètre de ces agents se pose avec un accord d'équipe avec l'IA, un canevas en accès libre sur ce site qui dit ce que l'IA peut faire et ce que l'humain se réserve. L'article Human Reserved, décider quels métiers restent humains raconte dans quelle équipe il est né.

Rien n'indique que la frontière décrite par Davenport et Mittal disparaisse quand l'outil devient plus capable. Un équipier qui sait beaucoup sans connaître le métier de l'équipe a besoin que quelqu'un lui traduise ce métier et vérifie ce qu'il en a compris. Ce que deviendra le rôle de traducteur face aux agents reste une question ouverte que le livre ne pouvait pas trancher.

D'où je parle

Depuis 2012, j'accompagne des équipes, des managers et des CODIR et je pratique la facilitation, dans une carrière commencée en 1998 dont quatorze ans à manager des équipes.

Par où commencer pour installer un traducteur ?

Par le prochain projet d'IA, sans créer de poste. Le rôle se teste avant de s'institutionnaliser, en quelques gestes qui disent s'il manque chez vous :

1. Nommer la personne qui répond de la question métier, distincte de celle qui construit le modèle.
2. Écrire le problème métier en une phrase avant toute modélisation, puis le confronter aux données et aux moyens disponibles.
3. Montrer tôt des prototypes aux futurs utilisateurs et recueillir leur avis à chaque étape.
4. Compter les systèmes réellement en production plutôt que les pilotes lancés.
5. Associer le manager de l'équipe concernée au choix du pilote et au suivi de ses résultats.

Si personne ne peut tenir le premier geste, le rôle manque. Un profil venu du métier, formé à la lecture des données, peut faire un meilleur premier traducteur qu'un recrutement extérieur.