Un projet IA qui n'a pas de pilote clair s'arrête tôt, ou dérape tard. Dans une ETI, la question se pose dès le premier cas d'usage : qui décide, qui arbitre, qui rend des comptes. Ni la DSI seule ni la direction métier seule ne suffisent à couvrir l'ensemble des enjeux. Cet article propose une grille de décision pratique pour répartir les responsabilités avant de lancer.
Ce qui compte n'est pas le nombre de personnes, mais l'absence de zone grise sur qui fait quoi.
Trois rôles à clarifier avant le lancement
Avant tout démarrage, trois rôles doivent être nommés, avec une personne identifiée pour chacun, pas une fonction abstraite.
Le sponsor porte la décision et l'arbitrage final. C'est un membre du comité de direction, DG, DAF, DRH ou COO selon le domaine concerné. Son rôle n'est pas d'exécuter, mais de trancher quand deux avis s'opposent et de garantir que le projet reste aligné avec les priorités de l'entreprise.
Le référent métier connaît le processus concerné dans le détail : ses exceptions, ses irritants, la façon dont le travail se fait réellement. Sans lui, l'outil retenu correspond rarement à l'usage réel.
Le référent technique évalue la faisabilité, la sécurité des données et l'intégration avec le système d'information existant. Sans lui, un cas d'usage prometteur peut se heurter à un mur technique découvert trop tard, ou exposer l'entreprise à un risque de sécurité non anticipé.
Ces trois rôles peuvent être portés par des personnes différentes ou, dans une ETI de taille plus modeste, par deux personnes qui cumulent certaines fonctions. Ce qui compte n'est pas le nombre de personnes, mais l'absence de zone grise sur qui fait quoi.
Le premier piège : tout confier à la DSI
Confier l'intégralité du pilotage à la DSI semble rassurant sur le papier : compétence technique, vision transverse, habitude de gérer des projets. Le risque est un ancrage métier trop faible. Un outil peut être bien intégré techniquement et pourtant rester inutilisé, parce qu'il n'a pas été conçu autour des tâches réelles d'un service. La DSI n'est pas toujours en mesure de juger seule ce qui vaut la peine d'être automatisé ou assisté, et ce jugement appartient d'abord à ceux qui font le travail.
Le deuxième piège : tout confier au métier
À l'inverse, laisser un service métier piloter seul un projet IA expose à une perte de cohérence technique et de sécurité. Des outils choisis sans validation peuvent multiplier les accès aux données de l'entreprise, créer des doublons avec des solutions déjà existantes, ou introduire des failles que personne n'a évaluées. Ce piège est d'autant plus fréquent que des outils grand public sont faciles d'accès et rapides à essayer, ce qui donne l'impression que le sujet ne nécessite pas d'arbitrage transverse.
Une méthode de répartition selon la nature du cas d'usage
La bonne répartition dépend moins d'un principe général que de la nature du cas d'usage.
Quand le cas d'usage touche un processus métier ciblé, avec un impact limité sur le système d'information et les données sensibles, le référent métier peut porter l'essentiel du pilotage opérationnel, avec un point de passage technique pour validation.
Quand le cas d'usage touche plusieurs services, des données sensibles, ou nécessite une intégration avec des outils existants, le pilotage doit être partagé de façon plus étroite entre référent métier et référent technique, avec des points de décision communs plutôt que des validations séquentielles.
Dans tous les cas, le sponsor reste responsable de l'arbitrage final et du calendrier. Cette clarté évite qu'un désaccord technique ou métier ne bloque le projet faute d'instance pour trancher.
Les signaux d'une gouvernance défaillante
Certains signaux indiquent, souvent tôt, qu'un projet est mal gouverné.
Personne ne tranche : les décisions s'accumulent sans être prises, les réunions se terminent sans arbitrage, le projet avance par inertie plutôt que par choix.
Tout le monde tranche : plusieurs personnes prennent des décisions contradictoires sans coordination, chacun croit porter le projet, et les équipes reçoivent des consignes différentes selon l'interlocuteur.
Dans les deux cas, la cause est la même : les rôles n'ont pas été formalisés au départ. La correction est rarement complexe, elle demande surtout de nommer explicitement qui est sponsor, qui est référent métier, qui est référent technique, et de le communiquer à toutes les parties concernées avant que le projet ne prenne de la vitesse.