Le rôle d'un operating partner IA : périmètre, compétences et gouvernance

Dans la plupart des directions financières, des fonds de capital-investissement (private equity), des family offices (structures qui gèrent le patrimoine d'une famille) et des cabinets d'expertise comptable, les expérimentations d'intelligence artificielle se multiplient. Une équipe teste un outil de synthèse de documents, une autre un assistant de rédaction, une troisième un prototype de prévision de trésorerie. Ces essais produisent souvent des démonstrations convaincantes et parfois des gains locaux, dont la mesure reste à établir, mais ils restent isolés et n'entrent presque jamais dans un fonctionnement durable. La question n'est donc plus de savoir si l'on peut réaliser un essai. Elle est de savoir qui décide de ce qui passe en production, qui en répond et comment on vérifie dans la durée que l'outil crée réellement de la valeur.

C'est le vide que cherche à combler la fonction d'operating partner IA. Le terme vient de l'univers du capital-investissement, où un operating partner (littéralement « partenaire opérationnel ») est un dirigeant expérimenté qui accompagne les équipes d'un fonds dans l'amélioration des entreprises détenues en portefeuille. Appliquée à l'intelligence artificielle (IA), la fonction devient une personne, ou une petite équipe, chargée de relier la stratégie, le métier, les données et la technologie, avec un objectif explicite : transformer des intentions d'usage en décisions, en déploiements maîtrisés et en résultats mesurés. Ce rôle n'est ni celui d'un développeur, ni celui d'un consultant qui remet un rapport puis disparaît, ni celui d'un comité qui se réunit sans jamais trancher.

Cet article décrit le périmètre de ce rôle, les compétences qu'il exige et les trois modes d'intervention possibles : ponctuel, récurrent ou sur un portefeuille. Il détaille aussi la gouvernance, c'est-à-dire l'ensemble des règles qui précisent qui décide, qui contrôle et qui répond. On y trouve les propriétaires de cas d'usage (les personnes du métier qui répondent de chaque application concrète de l'IA), le comité de pilotage IA (l'instance qui arbitre les priorités et les mises en production) et une matrice de responsabilités (un tableau qui précise qui fait, qui répond et qui est consulté). L'article se termine par les limites du rôle, des questions à poser avant de mandater quelqu'un et une checklist à imprimer. Cette lecture permet de mieux distinguer ce rôle des fonctions voisines, évaluer si votre organisation en a besoin et rédiger une lettre de mission qui précise les responsabilités et les points à trancher.

Pourquoi ce rôle devient nécessaire#

Trois écarts expliquent la difficulté. Ils sont souvent traités séparément, alors qu'ils se nourrissent les uns les autres.

Trois écarts à combler#

• L'écart entre métier et technologie. Les équipes financières savent décrire un processus de clôture, de rapprochement bancaire ou d'analyse d'un dossier d'investissement. Elles savent moins quelles étapes sont automatisables, avec quelles données et à quel niveau de fiabilité. À l'inverse, le directeur des systèmes d'information (DSI), responsable de l'ensemble des outils informatiques de l'entreprise, sait connecter des systèmes, mais il ne perçoit pas toujours la raison d'être d'un contrôle inscrit dans le processus métier. Personne n'assure alors la traduction entre les deux langages.
• L'écart entre démonstration et production. Une démonstration convainc en réunion. Un usage régulier suppose autre chose : des droits d'accès définis, des données suffisamment propres, une procédure de vérification, une formation des utilisateurs, une maintenance et un moyen de revenir au processus antérieur si l'outil défaille. Beaucoup d'essais, appelés pilotes (expérimentations limitées à un périmètre réduit), s'arrêtent à la frontière de la mise en production, c'est-à-dire du passage à un usage réel et régulier. Ce blocage tient moins à un manque de talent qu'à l'absence de quelqu'un chargé de le franchir.
• L'écart de responsabilité. Lorsqu'une synthèse produite par un modèle de langage (un programme entraîné sur de très grandes quantités de textes pour produire un texte plausible) contient une erreur, qui doit la repérer, qui la corrige et qui en répond auprès de la direction ? Sans réponse claire, les usages se répandent dans l'ombre, avec des risques de confidentialité et de traçabilité que personne ne peut évaluer.

Une tension particulière dans le capital-investissement#

Dans un fonds, les sociétés en portefeuille (les entreprises dans lesquelles le fonds a investi) n'ont pas toutes le même niveau de maturité numérique. Une entreprise industrielle peut disposer d'un système de gestion bien structuré, tandis qu'une autre travaille encore avec des tableurs partagés et des échanges de courriels. Le fonds souhaite une cohérence de méthode, mais il ne peut pas imposer une solution unique sans tenir compte des réalités de chaque entreprise ni de sa gouvernance propre. Le rôle d'operating partner IA se situe précisément à cette jonction : il définit un cadre commun, puis en adapte l'application à chaque situation.

Définir l'operating partner IA#

Un terme emprunté, une fonction élargie#

Dans le capital-investissement, l'operating partner est traditionnellement un professionnel ayant exercé des responsabilités opérationnelles, comme la direction commerciale, la direction industrielle ou la direction financière. Il intervient auprès des dirigeants des entreprises en portefeuille pour améliorer leur performance pendant la période de détention, c'est-à-dire le temps pendant lequel le fonds reste investisseur. Il n'est pas toujours actionnaire, d'où le mot « partner », qui désigne une collaboration de travail plutôt qu'une participation au capital.

Appliquée à l'IA, la fonction conserve cette posture : un regard extérieur à la routine opérationnelle, une connaissance des leviers de performance et une capacité à arbitrer. Elle ajoute une compétence technique suffisante pour dialoguer avec les équipes qui conçoivent ou intègrent les outils, ainsi qu'une compréhension des enjeux de données et de réglementation.

Une définition opérationnelle#

On peut définir l'operating partner IA comme la personne chargée de faire passer les usages de l'intelligence artificielle du stade d'idée à celui de capacité pilotée. Elle identifie les opportunités, les classe, vérifie qu'elles reposent sur des données exploitables, accompagne leur mise en production et veille à ce que leurs effets soient mesurés. Elle rend compte à la direction générale ou au fonds.

Une part importante de ces usages repose sur l'IA générative, c'est-à-dire sur des systèmes capables de produire du texte, des tableaux ou des synthèses à partir d'une consigne rédigée en langage courant. Cette famille ne couvre cependant pas tout. La prévision de trésorerie, la détection d'anomalies dans des écritures comptables ou le classement automatique de documents relèvent de techniques différentes, qui ont chacune leurs exigences de données et de contrôle. Un bon operating partner ne confond pas ces familles, car elles n'appellent pas les mêmes garde-fous.

Le périmètre du rôle#

Le périmètre d'un operating partner IA se définit par ce qu'il pilote, ce qu'il influence et ce qu'il laisse à d'autres. L'erreur la plus fréquente consiste à lui confier la totalité du sujet, ce qui transforme le rôle en guichet unique, indispensable en apparence et fragile en pratique. Le tableau suivant propose une répartition à discuter avant toute nomination.

Les quatre champs à couvrir#

• La sélection des cas d'usage. Le rôle choisit où l'IA a du sens, en évitant à la fois la dispersion et les projets qui ne touchent aucun indicateur suivi par la direction. Il s'agit moins de collectionner des idées que de concentrer l'effort sur quelques applications dont la valeur est plausible et vérifiable.
• La préparation des données. Un cas d'usage ne vaut que par les données qui l'alimentent. Le rôle inventorie les sources, repère les incohérences de définition (deux services qui appellent « client » des populations différentes, par exemple) et signale les chantiers préalables, souvent moins spectaculaires mais déterminants.
• La gouvernance du risque. Il vérifie que chaque usage dispose d'un contrôle proportionné à ses conséquences, d'une trace des décisions et d'une personne responsable. Il ne remplace pas les fonctions juridiques, mais veille à ce que leurs exigences soient intégrées au projet dès le départ.
• L'appropriation humaine. Un outil non adopté crée rarement une valeur mesurable. Le rôle veille à ce que les utilisateurs comprennent ce que l'outil fait et ne fait pas, qu'ils sachent quand le contrôler et qu'ils disposent d'un canal pour signaler un problème.

La création de valeur comme fil conducteur#

La création de valeur désigne l'augmentation durable de ce que l'organisation retire de son activité, une fois pris en compte les coûts et les risques. Dans une entreprise, elle s'exprime dans la croissance, les marges, la capacité d'investissement et la solidité financière. Dans un fonds, elle se traduit aussi dans la valeur de l'entreprise au moment de sa revente, car un acquéreur peut être davantage disposé à payer une organisation qu'il peut la comprendre, la piloter et la contrôler.

Pour un operating partner IA, la création de valeur est le critère qui relie toutes les décisions. Un outil séduisant qui ne modifie ni un revenu, ni une marge, ni un risque, ni une décision n'en crée probablement pas de valeur démontrable. Les leviers se regroupent en quatre familles.

• Le revenu. L'IA peut améliorer la préparation des offres commerciales, la personnalisation des échanges avec les clients ou le suivi des opportunités. L'effet se mesure par la proportion de propositions qui aboutissent à un accord, et non par une impression générale.
• Les coûts et les marges. La réduction des tâches répétitives, une meilleure répartition du temps des équipes et une moindre dépendance à des prestations externes sur des travaux standardisés peuvent constituer des gisements à examiner en priorité. La mesure porte sur le temps consacré aux tâches avant et après le changement, rapporté au coût total.
• La qualité des décisions. Des scénarios plus nombreux, mieux documentés et préparés avec moins d'effort peuvent aider la direction à comparer des options qu'elle n'aurait pas eu le loisir d'examiner. L'effet peut être réel, mais il reste indirect et se lit surtout dans la qualité des arbitrages documentés.
• Le risque. La détection plus systématique d'anomalies, la traçabilité des décisions et les contrôles documentés peuvent réduire la probabilité d'incidents coûteux. Leur valeur est souvent invisible tant que rien ne se produit, ce qui rend leur mesure délicate et justifie une méthode explicite.

Mesurer sans inventer de chiffres#

Un article sérieux sur ce sujet ne propose pas de valeur de référence, car elle dépendrait de chaque organisation. Il propose en revanche une méthode, qui doit être appliquée avant tout lancement.

• La situation de départ (baseline). Avant de lancer un cas d'usage, on décrit précisément le processus actuel : ses étapes, ses acteurs, ses erreurs connues, son temps de cycle. Sans cette photographie, toute amélioration reste une impression.
• L'indicateur clé de performance (KPI). Un KPI est un indicateur qui résume un objectif. Il doit être choisi avant le déploiement, relié à un levier de valeur et accompagné d'une règle de calcul écrite, pour que personne ne puisse le redéfinir après coup.
• L'attribution. Il faut distinguer ce qui relève de l'outil de ce qui relève d'une autre évolution, comme une réorganisation ou une variation d'activité. La comparaison avec un groupe témoin, c'est-à-dire un périmètre comparable qui n'utilise pas l'outil, reste la méthode la plus rigoureuse lorsqu'elle est possible.
• Le coût total. Il inclut les licences, le temps de conception, la formation, la conduite du changement (l'accompagnement des équipes dans la transformation, détaillé plus loin), la maintenance et le contrôle humain. Un coût omis fausse la lecture de tout le reste.

La formule de référence est simple. La valeur nette égale les avantages mesurés moins le coût total, ajustés du niveau de risque résiduel, c'est-à-dire du risque qui subsiste une fois les contrôles en place. Elle ne fournit pas de résultat prêt à l'emploi, mais elle impose de nommer chaque terme.

Les missions tout au long du cycle#

Le rôle s'exerce selon un cycle en quatre temps : cadrage, priorisation, déploiement et suivi. Ces étapes forment une boucle plutôt qu'une ligne droite, car les enseignements tirés du suivi alimentent le cadrage suivant. Une organisation qui n'a pas institutionnalisé cette boucle se retrouve avec des projets qui s'empilent sans jamais être évalués.

Le cadrage#

Le cadrage consiste à transformer une envie ou une idée en problème précis, avec des limites claires. Il comporte trois séquences.

• Le diagnostic. Il recense les processus susceptibles d'être améliorés, les données disponibles et les outils déjà utilisés. Il repère aussi les usages de l'ombre, c'est-à-dire les outils employés par des collaborateurs sans validation. Ceux-ci révèlent un besoin réel, mais aussi un risque de confidentialité, qu'il faut traiter sans sanctionner ceux qui les utilisent.
• La formulation du problème. Un bon cadrage décrit le problème avant la solution. « Nous voulons utiliser un modèle de langage » n'est pas un problème. « Les notes des comités d'investissement ne sont pas reliées aux décisions prises, ce qui rend le suivi des hypothèses difficile » en est un.
• La fiche de cas d'usage. Un cas d'usage désigne une application concrète de l'IA à un problème identifié. La fiche est le document unique qui le décrit : problème, utilisateur, données nécessaires, niveau de risque, critère de réussite et propriétaire désigné. Sans fiche, il n'y a pas de cas d'usage, seulement une intention.

La priorisation#

La priorisation consiste à classer les cas d'usage pour décider lesquels seront lancés, lesquels seront reportés et lesquels seront abandonnés. Elle repose le plus souvent sur une matrice qui croise l'impact potentiel et la faisabilité. L'impact est l'effet attendu sur les leviers de valeur, estimé de manière qualitative et assumée. La faisabilité agrège plusieurs facteurs : la qualité des données, la complexité technique, l'appétence des équipes et l'exposition au risque réglementaire.

Un troisième axe doit être intégré : le risque propre au cas d'usage. Une application qui influe sur une décision sensible, comme l'évaluation d'un crédit ou le tri de candidatures, exige des précautions supplémentaires, un contrôle humain renforcé et parfois une exclusion pure et simple. Prioriser, c'est aussi dire non, et c'est souvent la décision la plus difficile à faire accepter.

Le déploiement#

Le déploiement fait passer un cas d'usage de la fiche à l'usage réel. Il suit une séquence prévisible, dont chaque étape peut être refusée si ses conditions ne sont pas réunies.

• Le pilote encadré. Il s'agit d'un essai sur un périmètre limité, avec des critères de sortie écrits à l'avance : ce qui permettra de poursuivre, de corriger ou d'arrêter.
• La validation par le propriétaire. Le propriétaire du cas d'usage accepte les résultats et les règles d'usage. Sans cette validation, la mise en production n'a pas de porteur dans la direction.
• La mise en production. Elle désigne le passage à un usage régulier, intégré aux processus, avec des droits d'accès et une maintenance identifiés.
• La procédure de repli. Elle décrit comment revenir au processus antérieur si l'outil est indisponible ou si ses sorties deviennent douteuses. Une procédure qui n'a jamais été testée n'existe pas vraiment.
• La supervision humaine. Elle permet à une personne compétente de comprendre une sortie, de la contrôler et de la corriger avant qu'elle n'ait des conséquences. Ce principe revient souvent dans les approches réglementaires, à vérifier avec un juriste.

Le suivi#

Le suivi est l'étape la plus négligée. Une fois l'outil en place, il faut vérifier qu'il tient ses engagements dans la durée. Le rôle organise pour cela quatre types de contrôle : les indicateurs d'usage (qui utilise l'outil et pour quoi faire), la qualité des sorties mesurée sur un échantillon contrôlé, le suivi des incidents et la détection de dérive. La dérive désigne le phénomène par lequel les données ou les usages évoluent et la performance se dégrade sans que personne ne le remarque, parce que les conditions d'origine ont changé. Le suivi aboutit à une décision explicite de poursuivre, d'ajuster ou d'arrêter. Arrêter un cas d'usage est une décision de gouvernance comme une autre, et elle doit être traitée comme telle.

Les compétences attendues#

Le profil recherché combine rarement toutes ces compétences chez une même personne. Elles doivent donc être présentes dans le rôle, soit chez l'intervenant, soit au sein d'une équipe qui l'entoure. Cinq compétences apparaissent indispensables.

La compétence métier finance#

Un operating partner IA doit comprendre la logique d'un compte de résultat, d'un bilan, d'un plan de trésorerie ou d'un business plan (le plan d'affaires de l'entreprise). Il doit savoir ce qu'est une décision d'investissement, comment se déroulent une clôture comptable et le reporting, c'est-à-dire les rapports de gestion adressés à la direction, et quelles sont les contraintes d'un comité d'engagement. Cette connaissance ne sert pas à faire le travail des financiers, mais à proposer des cas d'usage qui touchent des indicateurs réellement suivis. Sans elle, le rôle produit des idées séduisantes que la direction financière n'adopte jamais, faute de les reconnaître comme utiles.

La compréhension des données#

Il ne s'agit pas de savoir programmer, mais de savoir d'où viennent les données, qui les produit, comment elles sont définies et quelles sont leurs limites. La notion de donnée de référence est centrale : c'est la source unique qui fait autorité pour une information donnée, comme le référentiel des clients ou la liste des plans comptables. La qualité des données se décline en plusieurs critères : leur exhaustivité (rien ne manque), leur exactitude, leur cohérence entre systèmes et leur fraîcheur. Un modèle reflète les données qui l'ont nourri, et il en reproduit les biais. Savoir lire ces limites évite de confier à une machine des décisions fondées sur des bases fragiles.

La conduite du changement#

La conduite du changement désigne l'ensemble des méthodes qui accompagnent les personnes dans une transformation : expliquer le pourquoi, impliquer les utilisateurs tôt, former, reconnaître les résistances légitimes, puis mesurer l'adoption. Le piège le plus fréquent est un outil qui fonctionne techniquement, mais que personne n'utilise, ou qui est utilisé d'une manière qui n'était pas prévue. Un operating partner IA doit savoir qu'une part importante de la valeur se joue dans les habitudes de travail, et non dans le code.

Le sens du risque#

Le sens du risque consiste à distinguer un risque acceptable d'un risque inacceptable, puis à concevoir les contrôles adaptés. Il implique d'anticiper les erreurs plausibles d'un modèle de langage, qui peut produire une réponse fluide et fausse, appelée hallucination (une production qui paraît juste sans l'être). Il suppose aussi de penser les scénarios de défaillance : que se passe-t-il si l'outil est indisponible, si ses réponses changent sans prévenir, si des données confidentielles sont saisies par erreur ? Enfin, il implique de savoir quand un humain doit valider et quand l'automatisation est acceptable.

La capacité à décider#

Un operating partner IA doit proposer des options argumentées, recommander clairement et faire trancher. Un rôle qui n'aboutit jamais à une décision devient un animateur de réunions. Cette capacité suppose aussi d'accepter les arbitrages impopulaires : abandonner un projet cher à une équipe, reporter un cas d'usage prometteur faute de données fiables, ou refuser une solution qui ne répond pas aux exigences de contrôle. La décision est le point où toutes les autres compétences se rencontrent.

Les trois modes d'intervention#

L'operating partner IA peut intervenir de trois façons, qui répondent à des besoins et à des niveaux de maturité différents. Le choix doit être explicite, car chaque mode produit des attentes, un calendrier et des risques distincts.

Le mode ponctuel#

Le mode ponctuel repose sur une mission délimitée, définie à l'avance par un objet précis : diagnostic initial, cadrage d'un premier cas d'usage, revue d'un projet en difficulté, préparation d'une décision d'investissement technologique. Il produit un livrable identifiable, comme un diagnostic, une feuille de route ou une série de recommandations. Il convient à une organisation qui souhaite un état des lieux honnête avant de s'engager. Sa principale faiblesse est que le livrable reste souvent sans suite si personne, en interne, ne le porte. Il faut donc prévoir dès le départ un propriétaire interne qui reprendra le travail.

Le mode récurrent#

Le mode récurrent prévoit une présence régulière, à une cadence fixée à l'avance. L'intervenant anime le comité de pilotage, arbitre les priorités, suit les indicateurs et soutient les propriétaires de cas d'usage. Il convient aux organisations engagées sur plusieurs chantiers simultanés, qui ont besoin d'une continuité de méthode. Sa vigilance porte sur la dépendance à une personne : si toute la connaissance repose sur un seul intervenant, son départ fragilise l'ensemble. Le mode récurrent doit donc inclure un plan de transmission, avec des documents, des modèles de fiche et des procédures écrites.

Le mode sur un portefeuille#

Le mode sur un portefeuille concerne un fonds ou un groupe qui souhaite intervenir de manière transversale sur plusieurs entités. Il vise à standardiser la méthode de sélection et de gouvernance, à partager les retours d'expérience, à éviter que chaque entreprise achète des outils comparables dans des conditions dispersées, et à veiller à la cohérence des règles de données et de conformité. Il présente trois limites. La première est une uniformisation excessive qui ignore les spécificités métier de chaque société. La deuxième est une tension entre la logique du fonds et l'autonomie opérationnelle de chaque dirigeant. La troisième est un risque de conflit d'intérêts si l'intervenant est lié à un fournisseur de solutions, ce qui impose une transparence sur ces liens.

Propriétaire de cas d'usage et comité de pilotage IA#

Deux instances structurent la gouvernance au quotidien. L'une est individuelle, l'autre collective. Elles doivent rester distinctes, car confondre la responsabilité d'un usage et la décision sur l'ensemble du portefeuille conduit à des blocages.

Le propriétaire de cas d'usage#

Le propriétaire de cas d'usage est la personne du métier qui répond de la réussite d'une application de l'IA, de sa valeur et de ses risques opérationnels. Il n'est pas forcément le plus technicien ; il est celui qui connaît le processus et qui en subira les conséquences. Ses responsabilités comprennent :

• La définition du besoin. Il décrit le problème à résoudre, les situations dans lesquelles l'outil sera utilisé et celles dans lesquelles il ne doit pas l'être.
• La validation des données. Il confirme que les données utilisées correspondent à la réalité du métier et il signale les écarts qu'il observe.
• L'acceptation des règles d'usage. Il valide la manière dont l'outil est employé, les contrôles à réaliser et les situations qui exigent une relecture humaine.
• La mesure de l'effet. Il contribue à la définition des indicateurs et vérifie qu'ils reflètent ce qu'il observe au quotidien.
• La décision locale. Il propose au comité l'extension, l'ajustement ou l'arrêt du cas d'usage.
• La conduite du changement de son équipe. Il porte l'appropriation auprès de ses collaborateurs, avec l'appui du rôle d'operating partner.

Deux défaillances sont fréquentes. Un cas d'usage sans propriétaire devient orphelin : personne ne répond des erreurs, et le projet s'essouffle dès que son initiateur change de poste. À l'inverse, un propriétaire trop technique, sans lien avec le métier, produit des outils performants en apparence mais peu utilisés, parce qu'ils ne correspondent pas aux pratiques réelles.

Le comité de pilotage IA#

Le comité de pilotage IA est l'instance collective qui décide des priorités, des mises en production et de la politique d'usage. Il réunit généralement la direction générale ou un de ses représentants, la direction financière, la direction des systèmes d'information, le responsable des données (parfois appelé directeur des données ou Chief Data Officer, la personne qui garantit la définition et la qualité des données de l'entreprise), une fonction juridique ou de conformité, un représentant du métier concerné et l'operating partner, qui en assure l'animation. Son rythme est régulier et fixé à l'avance, pour qu'il ne dépende pas de l'urgence du moment.

Son ordre du jour type comporte quatre points :

• Les décisions en attente. Elles concernent les cas d'usage à lancer, à valider ou à arrêter, chacun accompagné d'une recommandation argumentée.
• Les indicateurs. Le comité examine l'usage, la qualité des sorties et les incidents, sans se perdre dans le détail technique.
• Les risques nouveaux. Une évolution réglementaire, un incident ou un changement dans les données peut justifier une décision exceptionnelle.
• La politique d'usage. Le comité révise régulièrement la charte d'usage, c'est-à-dire les règles écrites qui précisent quels outils sont autorisés, quelles données peuvent être saisies, quelles vérifications sont obligatoires et qui peut lancer un nouvel usage.

Le comité doit être une instance de décision, et non de simple information. Si les décisions se prennent ailleurs, il devient un lieu de présentation, et la gouvernance se déplace dans des conversations informelles qui échappent à tout contrôle.

Gouvernance et matrice de responsabilités#

Une matrice de responsabilités indique, pour chaque activité, qui réalise le travail, qui répond du résultat, qui doit être consulté et qui doit être informé. La forme la plus courante est la matrice RACI, du nom de ses quatre lettres :

• R (Responsible) : réalise. La personne qui fait le travail. Une activité peut avoir plusieurs réalisateurs.
• A (Accountable) : répond et tranche. La personne qui a le dernier mot et qui rend compte. Une activité ne doit avoir qu'un seul A, sinon personne ne répond vraiment.
• C (Consulted) : consulté. La personne dont l'avis est sollicité avant la décision, sans qu'elle décide elle-même.
• I (Informed) : informé. La personne qui doit connaître la décision, sans y participer.

Le tableau suivant est un modèle de départ, à adapter à chaque organisation. Il illustre la répartition que l'on retrouve le plus souvent dans une entreprise ou un fonds de taille moyenne. La fonction juridique n'y figure pas en colonne pour des raisons de lisibilité ; elle doit cependant être consultée sur toutes les lignes touchant à la conformité et à la politique d'usage.

Plusieurs règles de lecture rendent ce tableau utile plutôt que décoratif :

• Un seul A par ligne. Lorsque deux personnes se considèrent comme responsables, la décision se prend par défaut ou se répète à chaque réunion. Le tableau doit désigner un seul répondant final, même si plusieurs personnes réalisent le travail.
• Pas de R sans A. Une activité confiée à quelqu'un sans que personne n'en réponde finit généralement par ne pas être faite, ou par être faite sans contrôle.
• Ne pas surcharger le comité. Le comité tranche les questions transversales. Les propriétaires répondent de leur périmètre. Si le comité se retrouve en A sur chaque ligne, il devient un goulot d'étranglement, et la matrice doit être revue.

Le rôle face aux autres acteurs#

La confusion la plus courante consiste à croire que l'operating partner IA remplace l'un des acteurs existants. Il n'en est rien : il se situe entre eux, et son efficacité dépend de la qualité de ces relations.

Le consultant#

Le consultant apporte une méthode, une expertise et un regard extérieur, généralement matérialisés par un livrable : une étude, un diagnostic, un cadre de décision. Sa mission est définie à l'avance et se termine à une échéance fixée par le contrat. L'operating partner se distingue par sa présence dans la durée : il anime les décisions, suit la mise en production et mesure les effets. Le consultant est évalué sur son livrable, l'operating partner sur la capacité du cas d'usage à tenir dans le temps. Un consultant peut toutefois être mobilisé comme appui ponctuel, sous la responsabilité de l'operating partner, sur un sujet technique ou juridique précis.

Le directeur des systèmes d'information (DSI)#

Le DSI est responsable de l'ensemble du système d'information : infrastructures, applications, sécurité et projets techniques. Les décisions d'architecture, d'hébergement, d'intégration et de sécurité des accès relèvent de lui. L'operating partner ne se substitue pas à lui ; il s'assure que les choix techniques servent un cas d'usage défini et que les contraintes de sécurité sont anticipées. La tension est réelle, car le DSI dispose de ressources limitées et d'un portefeuille de projets concurrents. L'operating partner doit donc inscrire ces demandes dans une priorisation partagée, et non les traiter une à une au gré des urgences.

Le responsable des données#

Le responsable des données gouverne les définitions, les référentiels, les droits d'accès, la qualité des données et leur conformité au règlement général sur la protection des données (RGPD), c'est-à-dire le cadre européen qui encadre la collecte et le traitement des données personnelles. C'est un partenaire indispensable. Il ne porte cependant pas nécessairement la valeur des usages ni leur adoption par le métier. L'operating partner s'appuie sur lui pour fiabiliser les données, tandis que le responsable des données s'appuie sur l'operating partner pour savoir quels chantiers sont réellement prioritaires.

Le responsable de l'innovation#

Le responsable de l'innovation explore les technologies, teste des prototypes, effectue une veille et mobilise les équipes autour d'idées nouvelles. Son horizon est plus long et sa logique est celle de l'exploration, qui accepte de nombreux essais sans lendemain. Le risque est que le prototype reste un prototype : beaucoup d'idées testées, peu de mises en production. L'operating partner ramène la discussion vers la décision, la mesure et l'usage réel. Les deux fonctions sont complémentaires : l'innovation alimente la liste des cas d'usage possibles, et l'operating partner la transforme en décisions.

Pourquoi la distinction compte#

Confondre ces rôles produit des effets précis, que la gouvernance doit anticiper :

• Le cumul. Confier à une même personne la décision technique et l'arbitrage des usages supprime un contrôle croisé. Le choix d'un outil peut alors servir la solution disponible plutôt que le besoin exprimé.
• La confusion. Un consultant qui porte le rôle emporte la connaissance avec lui à la fin de sa mission, ce qui laisse l'organisation dépourvue de mémoire opérationnelle.
• Le vide. Si chacun des acteurs ci-dessus pense que le sujet est porté par un autre, la boucle complète n'est tenue par personne, et les usages se multiplient sans suivi.

Les questions à poser avant de mandater quelqu'un#

Avant de nommer un operating partner IA, qu'il soit interne ou externe, les questions suivantes permettent de vérifier que le mandat est clair. Chacune est accompagnée de la raison qui justifie de la poser.

• Quel problème de création de valeur le mandat doit-il résoudre ? Un mandat formulé comme « préparer notre stratégie IA » est trop large pour être évalué. Un mandat qui cite un levier de valeur et une décision précise l'est beaucoup moins.
• Quelle décision doit-il éclairer ? Un mandat utile se termine par une décision identifiable, comme le lancement d'un premier cas d'usage, l'arrêt d'un projet ou la validation d'une politique d'usage.
• Quels cas d'usage existent déjà, et qui les porte ? Il faut connaître l'inventaire réel, y compris les usages de l'ombre, pour éviter de repartir de zéro ou de doubler des initiatives.
• Quelles données sont réellement accessibles, et à quelles conditions ? Une donnée théoriquement disponible, mais impossible à extraire ou à utiliser juridiquement, ne compte pas dans le calcul.
• Qui tranche en cas de désaccord entre le métier et la technique ? Sans réponse, chaque désaccord devient un blocage. Le mandat doit désigner l'instance qui décide.
• Quelle indépendance vis-à-vis des éditeurs de solutions et des prestataires ? Une personne qui tire un avantage financier d'une solution ne peut pas arbitrer objectivement entre plusieurs options. Cette transparence doit être écrite.
• Comment les résultats seront-ils mesurés, et qui valide la mesure ? Si le mandant et le mandataire ne s'accordent pas sur la méthode, aucun bilan ne sera accepté.
• Quel est le plan de transmission de la méthode ? La question de la sortie est souvent oubliée. Un rôle qui ne laisse ni documents, ni instances, ni compétences internes repart avec ce qui faisait sa valeur.
• Quelles obligations de confidentialité, de conservation et de traçabilité s'appliquent, et qui les vérifie avec un juriste ? Les règles sur les données personnelles et sur l'IA peuvent imposer des exigences à identifier dès le départ, dont l'interprétation doit être vérifiée avec un juriste.

Les limites du rôle#

Un rôle bien défini est d'abord un rôle bien borné. Les limites suivantes doivent être connues de la direction comme de l'intervenant, faute de quoi les attentes dépassent rapidement ce qui peut être fait.

• Il ne remplace pas la décision. L'operating partner éclaire, recommande et organise l'arbitrage. La décision reste celle du dirigeant, du comité ou du fonds, qui en porte la responsabilité.
• Il ne promet pas de résultat. La valeur d'un cas d'usage dépend de la qualité des données, de l'adoption par les équipes, du contexte concurrentiel et de la qualité du cadrage initial. Un intervenant sérieux décrit des méthodes et des critères, pas des effets acquis d'avance.
• Il ne compense pas un système d'information fragmenté. Lorsque les données sont dispersées entre des outils non reliés, le rôle peut en révéler l'ampleur, mais il ne peut pas la résorber seul. Ce chantier relève de la direction des systèmes d'information et de la stratégie générale.
• Il n'est pas une fonction juridique. Il identifie les points de vigilance, mais l'interprétation des obligations réglementaires doit être vérifiée avec un juriste, notamment pour les usages qui touchent à des décisions concernant des personnes.
• Il ne doit pas devenir un goulot d'étranglement. Si toutes les décisions passent par lui, il ralentit l'organisation qu'il est censé accompagner. Sa mission est aussi de transférer la méthode à des propriétaires capables de l'appliquer.
• Il dépend de l'accès à la réalité des processus. Sans observation directe du travail quotidien, ses recommandations restent théoriques et risquent de méconnaître les exceptions qui font la complexité d'un métier.
• Il doit composer avec les limites des modèles. Un modèle de langage peut produire une réponse fluide et fausse, appelée hallucination. Il peut aussi reproduire des biais, c'est-à-dire des tendances systématiques présentes dans les données, ou réagir différemment selon la formulation d'une consigne. Le rôle organise la vérification, il ne la supprime pas.

Le cadre réglementaire : quatre principes à traduire en pratique#

Le règlement européen sur l'intelligence artificielle, couramment appelé AI Act, organise les usages de l'IA selon une approche par niveau de risque. Sans entrer dans le détail des obligations, qui doivent être vérifiées avec un juriste, quatre principes guident la gouvernance du rôle.

• L'approche par niveau de risque. Le règlement distingue, à faire confirmer par un juriste, des niveaux de risque allant de l'inacceptable au minimal. Plus un usage peut peser sur les droits d'une personne ou sur une décision importante, plus les exigences de contrôle sont fortes. La première tâche d'un operating partner est donc de classer chaque cas d'usage selon ce niveau.
• La transparence. Selon les règles à faire confirmer par un juriste, les personnes doivent être informées lorsqu'elles interagissent avec un système d'IA, et les usages doivent être documentés : finalité, données, limites connues. Selon les règles à faire confirmer par un juriste, cette exigence peut concerner aussi les documents produits à l'aide d'IA lorsque leur lecteur pourrait les prendre pour des productions humaines.
• La supervision humaine. Une personne compétente doit pouvoir comprendre les sorties d'un système, les contrôler et les corriger. La supervision n'est pas une relecture formelle : elle suppose que le relecteur dispose des informations et du temps nécessaires pour exercer un jugement réel.
• La traçabilité. Il faut pouvoir reconstituer ce qui s'est passé : versions de l'outil, données utilisées, consignes, sorties et décisions prises à partir de ces sorties. Une organisation qui ne trace rien ne peut ni corriger ses erreurs ni répondre à une demande de contrôle.

Glossaire#

• Operating partner : dirigeant expérimenté qui accompagne les équipes d'un fonds ou d'une entreprise pour améliorer leur performance. Dans cet article, la personne chargée des usages de l'IA sur la durée.
• Création de valeur : augmentation durable de ce que l'organisation retire de son activité, après prise en compte des coûts et des risques.
• Société en portefeuille : entreprise dans laquelle un fonds de capital-investissement a investi et dont il suit la performance.
• Période de détention : le temps pendant lequel le fonds reste investisseur dans une entreprise, avant de la revendre.
• Conduite du changement : ensemble des méthodes qui accompagnent les personnes dans une transformation, de l'explication à la formation et à la mesure de l'adoption.
• Propriétaire de cas d'usage : personne du métier qui répond de la réussite, de la valeur et des risques opérationnels d'une application de l'IA.
• Comité de pilotage IA : instance collective qui décide des priorités, des mises en production et de la politique d'usage.
• Charte d'usage : règles écrites qui précisent les outils autorisés, les données admises à la saisie, les contrôles obligatoires et les conditions de lancement d'un nouvel usage.
• Matrice RACI : tableau qui répartit les responsabilités entre réalisation (R), obligation de rendre compte et de trancher (A), consultation (C) et information (I).
• Directeur des systèmes d'information (DSI) : responsable de l'ensemble des outils informatiques, des infrastructures, de la sécurité et des projets techniques.
• Responsable des données : personne qui garantit la définition, la qualité, les référentiels et la conformité des données de l'entreprise.
• Responsable de l'innovation : personne qui explore les technologies, teste des prototypes et fait la veille sur les usages émergents.
• IA générative : famille de systèmes capables de produire du texte, des tableaux ou des synthèses à partir d'une consigne en langage courant.
• Modèle de langage : programme entraîné sur de très grandes quantités de textes pour produire un texte plausible en réponse à une consigne.
• Hallucination : production d'un modèle qui paraît juste et bien formulée, mais qui contient une information fausse.
• Dérive : dégradation progressive de la performance d'un système lorsque les données ou les usages évoluent sans que le dispositif de suivi ne le détecte.
• Donnée de référence : source unique qui fait autorité pour une information donnée, comme le référentiel des clients.
• Situation de départ (baseline) : description précise d'un processus avant l'introduction d'un outil, qui sert de point de comparaison.
• Indicateur clé de performance (KPI) : indicateur qui résume un objectif, choisi avant le déploiement et accompagné d'une règle de calcul écrite.
• Groupe témoin : périmètre comparable qui n'utilise pas l'outil, afin d'isoler l'effet de celui-ci.
• Pilote : essai encadré sur un périmètre limité, destiné à vérifier la faisabilité et la valeur avant une généralisation.
• Mise en production : passage d'un essai à un usage régulier, intégré aux processus, avec des droits, une maintenance et une procédure de repli.
• Supervision humaine : principe selon lequel une personne compétente peut comprendre, contrôler et corriger les sorties d'un système.
• Traçabilité : capacité à reconstituer les données, versions, consignes, sorties et décisions associées à un usage.
• Usage de l'ombre : outil utilisé par des collaborateurs sans validation de l'organisation.
• Risque résiduel : risque qui subsiste une fois les contrôles mis en place.
• RGPD : règlement général sur la protection des données, qui encadre la collecte et le traitement des données personnelles dans l'Union européenne.
• AI Act : règlement européen qui encadre les usages de l'intelligence artificielle par niveau de risque, à faire vérifier par un juriste.

Checklist à imprimer#

• Le problème à résoudre est formulé en termes de création de valeur, sans partir d'une technologie.
• Une décision précise est attendue à la fin de la mission.
• La liste des cas d'usage existants, y compris les usages de l'ombre, a été établie.
• Chaque cas d'usage dispose d'une fiche avec un propriétaire désigné.
• Les données nécessaires sont identifiées, leur accès est confirmé et leur qualité est évaluée.
• Le niveau de risque de chaque usage est classé selon l'approche par niveau de risque.
• Une situation de départ (baseline) est décrite avant tout lancement.
• Un indicateur clé est choisi, avec sa règle de calcul écrite.
• Le coût total est recensé, y compris la formation et le contrôle humain.
• La supervision humaine est prévue pour chaque sortie qui pèse sur une décision.
• Une procédure de repli a été rédigée et testée.
• Le comité de pilotage IA est désigné, avec un rythme fixé à l'avance.
• La matrice de responsabilités ne comporte qu'un seul répondant final par activité.
• La charte d'usage précise les outils autorisés et les données interdites à la saisie.
• Les obligations de confidentialité et de traçabilité ont été vérifiées avec un juriste.
• Les liens éventuels avec des éditeurs ou des prestataires ont été déclarés.
• Un plan de transmission de la méthode est prévu.
• Une revue de suivi est programmée, avec un critère clair de poursuite, d'ajustement ou d'arrêt.

Questions fréquentes#

Un operating partner IA doit-il venir de la finance ?#

Pas nécessairement, mais il doit en comprendre la logique. Un profil issu de l'informatique peut réussir s'il s'entoure de partenaires métier solides et s'il acquiert une connaissance réelle des décisions financières. L'inverse est vrai aussi : un financier doit accepter de comprendre les contraintes des données. Ce qui compte est la capacité à traduire entre les deux mondes.

Quelle différence avec un consultant qui présente une étude ?#

Le consultant livre une analyse et un plan, puis sa mission se termine. L'operating partner reste dans la boucle : il suit la mise en production, anime les décisions et contrôle les effets. Un consultant peut toutefois intervenir ponctuellement dans un dispositif piloté par un operating partner.

Peut-on confier ce rôle à un collaborateur interne ?#

Oui, à condition qu'il dispose d'un temps réellement dédié, d'un mandat écrit et d'une autorité reconnue par le comité. Un rôle ajouté à une fonction principale, sans temps ni légitimité, produit surtout de l'intention. Le choix interne peut offrir une meilleure continuité, mais il expose à des conflits avec les équipes qu'il doit arbitrer.

Comment éviter que le rôle devienne un goulot d'étranglement ?#

En transférant la méthode. La fiche de cas d'usage, la grille de priorisation, le modèle de tableau de bord et la charte d'usage doivent être rédigés, partagés et appliqués par les propriétaires. Il faut aussi fixer des seuils au-delà desquels une décision est prise localement, sans remonter au comité.

Faut-il un rôle à temps plein ?#

Cela dépend de la taille de l'organisation ou du portefeuille et du nombre de cas d'usage en cours. Un mode ponctuel ou récurrent peut suffire à une organisation qui démarre. Un fonds dont plusieurs entreprises sont engagées dans des chantiers simultanés peut justifier une présence plus soutenue. La charge de travail doit être estimée avant la décision, à partir de la liste des missions, et non d'une intuition.

Conclusion#

La fonction d'operating partner IA répond à un besoin concret : relier des usages de l'intelligence artificielle à des décisions, à des responsabilités et à des effets mesurables. Son périmètre couvre le cadrage, la priorisation, le déploiement et le suivi, et s'appuie sur des compétences en finance, en données, en conduite du changement, en gestion du risque et en décision. Elle s'exerce selon trois modes, ponctuel, récurrent ou sur un portefeuille, qui doivent être choisis en fonction de la maturité de l'organisation.

Sa force est aussi sa limite. Le rôle n'a de sens que s'il reste borné : il éclaire les décisions sans les remplacer, il organise la vérification sans prétendre supprimer l'erreur, et il transmet sa méthode plutôt que de la conserver. Une matrice de responsabilités claire, un comité de pilotage qui tranche réellement et des propriétaires de cas d'usage identifiés sont des conditions favorables pour que ce rôle puisse produire de la valeur. Avant de mandater quelqu'un, les questions présentées ici permettent de vérifier que ces conditions existent, ou de savoir par où commencer.