DSI : votre problème IA est peut-être un problème de gouvernance métier

La plupart des projets IA commencent par une demande apparemment technique : prévoir, scorer, prioriser, recommander, automatiser.

Puis ils se grippent.

Les données existent. Les démonstrateurs sont convaincants. Les équipes techniques savent construire un prototype. Pourtant, au moment de passer à l’usage, les prévisions sont contestées, les recommandations suscitent la méfiance et les métiers réclament des exceptions.

Chaque région veut conserver ses règles. Chaque équipe défend son contexte. Le pilote fonctionne, mais personne n’accepte vraiment de s’y fier.

Le diagnostic tombe alors, presque mécaniquement : données insuffisantes, historique incomplet, modèle perfectible, compétences à renforcer.

Ces défauts sont parfois réels. Mais ils servent aussi d’alibi commode à des décisions que personne ne veut prendre.

Car une donnée incohérente n’est pas toujours une donnée sale. C’est parfois la trace laissée par un arbitrage que l’entreprise n’a jamais osé rendre.

Le problème devient alors plus inconfortable : qui a l’autorité pour définir les règles selon lesquelles l’entreprise décide ?

Pour une DSI, l’enjeu est décisif. À défaut d’arbitrage métier, ce sont les systèmes qui finiront par porter — et payer — les contradictions de gestion.

L’IA retire à l’entreprise le confort de ses ambiguïtés

Une organisation peut vivre longtemps avec des définitions imprécises.

Un tableau Excel permet à chaque équipe de conserver ses conventions. Un manager expérimenté réinterprète les chiffres selon le contexte. Une direction régionale adapte une règle sans la formaliser. Tant que les outils restent fragmentés, ces écarts paraissent gérables. Ils restent surtout peu visibles.

L’IA change la nature du problème.

Pour recommander, classer, prévoir ou automatiser, un système doit s’appuyer sur des critères explicites. Il ne se contente pas de conserver l’information : il l’interprète pour produire une action possible.

Il oblige donc l’entreprise à répondre à des questions qu’elle pouvait jusque-là contourner.

L’IA ne crée pas toujours la confusion. Elle rend visible celle que l’entreprise avait appris à tolérer.

Une règle non tranchée devient une recommandation contestée

Qu’est-ce qu’un client à risque ? À partir de quel seuil un dossier devient-il prioritaire ? Quand une opportunité commerciale mérite-t-elle d’entrer dans les prévisions ?

Un modèle peut repérer des régularités dans un historique. Il ne peut pas arbitrer durablement entre plusieurs définitions concurrentes d’une même réalité.

Si une direction commerciale, une business unit et une région donnent trois sens différents au mot « opportunité mature », le système finira nécessairement par produire une réponse discutable. Non parce qu’il serait mal conçu, mais parce qu’aucune autorité n’a décidé ce que le terme devait recouvrir.

Un projet IA devient alors plus exigeant qu’un projet informatique classique. Il ne demande pas seulement des données, une architecture et un budget. Il demande un accord sur les règles qui gouvernent l’action.

La « mauvaise qualité » des données peut être un problème de pouvoir

Il existe, bien sûr, des données objectivement défectueuses : doublons, erreurs de saisie, flux mal intégrés, historiques incomplets, données indisponibles.

Mais certaines incohérences relèvent moins d’un défaut technique que de pratiques de gestion incompatibles.

Une équipe commerciale peut déclarer très tôt un grand nombre d’opportunités pour démontrer son dynamisme. Une autre attendra la validation d’un budget client afin de protéger la crédibilité de son pipeline. Dans les deux cas, la donnée ne raconte pas seulement une transaction. Elle traduit une manière de piloter l’activité.

La nettoyer sans traiter la règle qui la produit revient à industrialiser l’ambiguïté.

La question n’est donc pas uniquement : comment fiabiliser la donnée ?

Elle devient : qui est légitime pour décider de ce qu’elle doit signifier ?

Prévoir les ventes quand personne ne parle du même pipeline

La prévision commerciale est l’un des cas d’usage IA les plus séduisants. Les CRM contiennent des années d’historique, les cycles de vente semblent documentés, les opportunités gagnées et perdues sont enregistrées.

Sur le papier, tout est réuni.

Une direction commerciale demande à la DSI un modèle capable de prévoir le chiffre d’affaires à venir et d’identifier les opportunités les plus susceptibles d’être signées. L’objectif est légitime : mieux répartir les ressources, anticiper les objectifs trimestriels, détecter les risques de sous-performance et aider les managers à concentrer leurs efforts.

Le prototype est rapidement disponible.

Les données des régions sont consolidées. Le modèle calcule une probabilité de signature à partir du secteur, de la taille du client, de l’ancienneté de l’opportunité, des interactions enregistrées et des résultats passés.

Puis les discussions commencent.

Dans une région, une opportunité est créée dès le premier rendez-vous. Dans une autre, elle n’existe qu’après validation d’un budget client.

Certaines équipes mettent à jour leurs probabilités chaque semaine. D’autres attendent l’approche de la clôture trimestrielle. Une probabilité de 70 % signifie « proposition envoyée » pour les unes, « accord verbal obtenu » pour les autres.

Certains commerciaux ferment rigoureusement les dossiers perdus. D’autres les laissent ouverts, au cas où la relation reprendrait.

Le modèle peut produire une prévision mathématiquement cohérente à partir des données disponibles. Mais cette prévision reste managérialement inutilisable : elle additionne des réalités qui ne sont pas comparables.

À ce stade, l’entreprise doit choisir ce qu’elle veut réellement optimiser : la vitesse locale ou la cohérence collective.

Adapter le modèle ou unifier la règle de gestion

La première option consiste à construire plusieurs modèles, adaptés aux pratiques de chaque région.

L’avantage est immédiat : moins de résistance, une livraison plus rapide, une meilleure acceptation locale. Mais le prix est rarement assumé. L’entreprise institutionnalise sa fragmentation. Elle obtient une collection de systèmes utiles ici ou là, sans jamais construire une vision commerciale commune.

La seconde option consiste à définir un pipeline partagé : étapes, probabilités, règles de clôture, traitement des opportunités dormantes, critères de maturité.

Le coût est politique. Il faut remettre en cause des habitudes, arbitrer des intérêts locaux et accepter qu’une règle commune ne reproduise parfaitement aucune pratique existante.

Mais le bénéfice est structurel : les prévisions deviennent comparables, les écarts deviennent lisibles et le pilotage cesse de dépendre de la capacité de quelques experts à « interpréter » les chiffres.

Ce choix ne relève pas de la DSI seule. Il engage la direction commerciale. Et lorsque les intérêts locaux rendent l’accord impossible, il devient une responsabilité de direction générale.

Quatre signaux qu’un problème de gouvernance se cache derrière votre projet IA

1. Personne ne peut nommer le propriétaire de la décision

Un projet IA sérieux doit être relié à une décision précise : prioriser un dossier, relancer un client, affecter une ressource, détecter un risque, autoriser une exception.

La première question n’est donc pas technique : qui est responsable de cette décision ?

Qui peut modifier la règle métier ? Qui tranche lorsqu’un manager conteste le système ? Qui assume les conséquences lorsqu’une recommandation est suivie et produit un mauvais résultat ?

Si la réponse est « l’équipe projet », « la data » ou « la DSI », le problème est mal posé.

Une technologie peut éclairer une décision. Elle ne remplace pas l’autorité qui doit en assumer les critères.

2. Les indicateurs clés changent de sens selon les équipes

Client actif, churn, marge, stock disponible, incident résolu, dossier complet, délai de traitement : ces termes paraissent simples jusqu’au moment où il faut les utiliser dans un système commun.

Un client est-il actif après une commande, après une facture payée ou après une interaction récente ? Un incident est-il résolu lorsqu’il est techniquement fermé, lorsque le client est informé ou lorsque la cause racine a été traitée ?

Un indicateur n’est jamais un simple champ dans une base de données. C’est une convention de management.

Tant que cette convention demeure implicite, la précision apparente du système masque l’instabilité réelle des critères.

3. L’entreprise demande au système de compenser un processus instable

Prenons le cas d’un assureur qui veut prioriser automatiquement les dossiers clients.

Le problème apparent est l’hétérogénéité des données entre agences. Mais le blocage peut se situer ailleurs : les critères d’urgence, de dossier complet ou de client sensible ne sont pas appliqués de la même manière selon les équipes.

L’outil peut accélérer le tri. Il ne peut pas inventer un processus de résolution partagé.

Avant de confier une priorisation à un système, l’entreprise doit décider ce qui compte comme prioritaire — et qui est légitime pour le dire.

4. Les exceptions locales sont devenues la règle

Certaines phrases devraient alerter une DSI :

• « Chez nous, c’est un peu différent. »
• « Cette donnée est seulement indicative. »
• « Il faut connaître le contexte. »
• « On ne peut pas comparer les régions. »
• « Le système ne reflète pas la réalité du terrain. »

Ces objections ne sont pas nécessairement infondées. Une entreprise internationale, un réseau de franchises ou un groupe multi-activités ne peut pas tout uniformiser.

Le sujet n’est pas d’abolir toute diversité locale. Il est de décider ce qui doit rester local, ce qui doit devenir commun et qui peut valider l’écart.

Chaque exception paraît raisonnable lorsqu’elle est examinée isolément. Leur accumulation finit par produire une entreprise impossible à piloter.

Quand la DSI code les désaccords métier

Le mécanisme est classique.

Les métiers formulent un besoin. La DSI tente de le traduire en données, règles et outils. Les arbitrages non rendus remontent vers le projet. Pour éviter le blocage, les équipes techniques créent des paramétrages, des règles de contournement ou des exceptions locales.

La solution avance, en apparence.

Mais elle devient plus complexe, plus fragile et plus coûteuse à maintenir.

Quand la DSI code des désaccords métier, elle ne livre pas une solution : elle transforme un conflit de gouvernance en dette technique.

La tentation est compréhensible. Le sponsor veut des résultats visibles. Les budgets IA sont exposés. Les métiers demandent un pilote rapide. La DSI ne veut pas être accusée de freiner l’innovation.

Le contournement semble plus pragmatique que l’arbitrage.

Pourtant, le problème ne disparaît pas. Il réapparaît plus tard dans le code, les référentiels, les incidents, les demandes d’évolution et les contestations d’usage.

Au début, rien n’échoue vraiment. Le modèle est seulement discuté, contourné, puis réservé à quelques initiés. C’est ainsi qu’un pilote devient une dette.

Les résultats sont contestés dès leur première utilisation. Les règles et les modèles se multiplient. La confiance dans la donnée baisse. Quelques experts deviennent indispensables parce qu’eux seuls savent encore « interpréter » les résultats.

La technologie devient alors le terrain visible d’un désaccord que l’organisation n’a jamais traité à sa source.

Le rôle stratégique de la DSI : rendre le problème gouvernable

La DSI n’a pas vocation à bloquer les métiers au nom d’une pureté méthodologique. Elle n’a pas non plus à absorber silencieusement leurs contradictions.

Son rôle est de rendre les choix visibles, traçables et opérables.

Dans tout cadrage IA, trois catégories de questions devraient être distinguées.

1. Les questions techniques : architecture, intégration, sécurité, performance, exploitation.<br>2. Les questions de données : disponibilité, historique, granularité, fiabilité des flux.<br>3. Les questions de gestion : définition des règles, propriétaire de la décision, critères d’exception, responsabilité en cas de désaccord.

Cette séparation est simple. Elle change pourtant la nature du dialogue.

L’objectif n’est pas de renvoyer le problème aux métiers. Il est d’empêcher qu’un projet se présente comme technique alors qu’il exige une décision de direction.

Une règle explicite, même imparfaite, vaut mieux qu’une sophistication opaque

Une entreprise n’a pas besoin d’attendre une définition parfaite pour avancer.

Une règle commune sera imparfaite au départ. Elle devra évoluer. Elle provoquera des discussions. Mais elle sera plus utile qu’un modèle très avancé fondé sur cinq définitions contradictoires.

La maturité ne consiste pas à tout figer. Elle consiste à rendre les choix explicites, discutables et révisables.

Le responsable commercial doit porter la définition du pipeline. Le responsable crédit doit assumer les règles de priorisation du risque. Le responsable opérations doit répondre des critères de traitement d’une commande.

La DSI garantit que ces règles peuvent être traduites en systèmes fiables, sécurisés et maintenables.

Elle ne décide pas seule du sens de la donnée. Mais elle peut refuser de masquer l’absence de décision derrière une sophistication technique.

La question à poser en comité

Avant de demander à la DSI de livrer une nouvelle solution, posez cette question :

Quel arbitrage de gestion sommes-nous prêts à rendre avant de demander une réponse technique ?

Elle oblige à sortir du réflexe de l’outil. Elle révèle aussi si le comité cherche réellement à améliorer une décision — ou s’il espère que la technologie évitera une discussion inconfortable.

Quelques questions doivent suivre :

• Quelle décision précise voulons-nous améliorer, accélérer ou sécuriser ?
• Qui la prend aujourd’hui ?
• Qui sera responsable de la règle utilisée demain ?
• Les équipes partagent-elles la même définition des indicateurs clés ?
• Quelles exceptions sont légitimes, et qui peut les valider ?
• Que ferons-nous lorsqu’une recommandation contredira l’intuition d’un manager ?

Si ces questions n’ont pas de réponse, le projet n’est pas encore un projet IA.

C’est un désaccord d’organisation en attente de décision.

À retenir

• Un projet IA bloqué ne révèle pas toujours un défaut de modèle ou de données.
• Des données incohérentes peuvent signaler une gouvernance métier absente ou non assumée.
• La diversité locale n’est pas un problème en soi ; l’absence de cadre pour la gouverner en est un.
• La DSI ne doit pas convertir chaque ambiguïté de gestion en exception technique.
• Avant d’automatiser une décision, l’entreprise doit pouvoir en nommer les critères, le propriétaire et les conséquences.

Un projet IA sérieux ne commence pas par le choix d’un modèle. Il commence par une décision de gouvernance : ce qui doit être commun, ce qui peut rester local, et qui répondra des règles retenues.

Un arbitrage prend parfois plus de temps qu’un prototype. Mais une décision explicite, même imparfaite, coûte moins cher qu’une architecture construite pour contourner ce que l’organisation refuse de trancher.

C’est cette frontière — entre technologie utile et couche de compensation organisationnelle — qu’explore La couche IA.

Pour aller plus loin : découvrez La Couche IA , ou achetez le livre sur Amazon .