Pourquoi votre DSI ne peut pas porter seule la transformation IA

Un comité de direction demande à la DSI de « lancer l’IA ».

La demande paraît technique. Elle ne l’est pas.

Derrière ce mot se cachent des décisions que personne ne veut encore prendre : quel processus faut-il réellement changer ? Quelle erreur peut être acceptée ? Quelle donnée fait autorité ? Qui valide le résultat ? Qui répond de ses conséquences ?

La DSI devient alors le point de passage obligé. Elle doit choisir les outils, sécuriser les données, contrôler les fournisseurs, intégrer les solutions et produire des résultats visibles en trois mois.

Mais on lui demande rarement de décider ce que l’entreprise veut réellement transformer.

On lui confie la responsabilité du mouvement sans lui donner le droit de choisir sa destination. Elle doit accélérer l’adoption tout en répondant des erreurs métier. Elle doit rendre les usages possibles sans savoir qui les assumera.

C’est ainsi que la DSI devient la couche de compensation d’une organisation qui refuse encore de trancher.

La question n’est donc pas de savoir si votre DSI est « prête pour l’IA ».

La vraie question est plus exigeante : l’entreprise est-elle capable de décider collectivement de ses usages, de ses risques et de ses responsabilités ?

Le premier piège : confondre transformation IA et déploiement d’outils

Un modèle, un assistant ou une plateforme ne définit ni le problème à résoudre ni la responsabilité qui en découle.

Avant de choisir une solution, il faut savoir :

• quel problème doit être traité ;
• dans quel processus l’outil intervient ;
• quelle décision sera influencée ;
• quelles données feront autorité ;
• quel niveau d’erreur est acceptable ;
• dans quelles situations l’intervention humaine reste obligatoire.

Ces questions ne sont pas techniques. Elles touchent à l’organisation du travail, à la qualité attendue et à la répartition du pouvoir de décision.

Le meilleur outil du marché reste inutile lorsqu’il accélère un processus que personne n’a accepté de remettre en cause. Il peut même rendre une mauvaise pratique plus rapide, plus opaque et plus difficile à corriger.

La DSI peut choisir une solution. Elle ne peut pas inventer le besoin métier.

Prenons une direction qui demande à la DSI de déployer une solution d’intelligence artificielle pour « gagner du temps sur les demandes entrantes ».

La demande semble précise. Elle ne l’est pas.

De quelles demandes parle-t-on ? Lesquelles sont répétitives ? Quelles réponses peuvent être standardisées ? Quelles exceptions exigent une expertise ? Quelle erreur est acceptable ? Quand faut-il reprendre la main ?

Sans ces réponses, la DSI peut installer une solution. Elle ne peut pas inventer la règle métier qui permettra de juger ses résultats.

Il faut distinguer quatre décisions souvent mélangées :

1. Qualifier le problème et le cas d’usage ;<br>2. Repenser le processus concerné ;<br>3. Définir le niveau de qualité et de risque acceptable ;<br>4. Choisir, intégrer et sécuriser la solution.

La quatrième relève largement de la DSI.

Les trois premières appartiennent aux métiers, à la direction et aux fonctions de contrôle. Une technologie ne peut pas décider à la place des ressources humaines quels biais sont inacceptables, ni à la place d’un responsable commercial si une recommandation est pertinente.

La DSI rend l’IA possible. Elle ne rend pas l’entreprise responsable à la place des métiers.

Le rôle réel de la DSI dans la gouvernance IA

La DSI n’a pas moins de responsabilités. Elle en a de plus précises.

Sécuriser le socle et rendre les limites visibles

La DSI doit construire les conditions de confiance nécessaires à l’expérimentation et au déploiement IA :

• gestion des identités et des accès ;
• protection des données sensibles ;
• interconnexion avec les systèmes existants ;
• traçabilité des usages ;
• supervision des solutions ;
• continuité de service et réversibilité ;
• maîtrise des fournisseurs et des dépendances ;
• contrôle des coûts et de la consommation.

Elle doit aussi rendre visibles les fragilités techniques : données incomplètes, sources contradictoires, historique peu fiable, intégrations instables ou impossibilité d’auditer une solution.

Ce travail est décisif. Mais il ne constitue pas une validation globale du cas d’usage.

Une solution peut être parfaitement sécurisée et totalement inadaptée au processus auquel on la destine.

Organiser l’expérimentation sans fabriquer une bureaucratie

La DSI peut établir un cadre commun :

• solutions autorisées ;
• données interdites ou sensibles ;
• règles de partage ;
• exigences de validation humaine ;
• critères de passage du test à l’industrialisation ;
• conditions d’arrêt ;
• modalités de suivi.

Mais ce cadre ne doit pas devenir une procédure supplémentaire que personne ne comprend ni n’applique.

Une gouvernance utile ne consiste pas à produire davantage de formulaires. Elle consiste à rendre explicites les décisions qui doivent être prises, par les bonnes personnes, au bon moment.

Le métier définit la valeur. La direction accepte le risque. La DSI construit les conditions de déploiement. Les fonctions de contrôle fixent les limites.

Lorsque ces rôles se mélangent, chacun croit être couvert — et personne ne l’est réellement.

Savoir dire non, sans devenir le responsable de tout

La DSI doit pouvoir refuser :

• un usage exposant des données critiques ;
• une solution impossible à auditer ;
• une dépendance fournisseur mal maîtrisée ;
• une automatisation sans responsable désigné ;
• un déploiement dont les conditions de fiabilité ne sont pas réunies.

Mais elle ne doit pas être la seule à porter le refus.

Interdire un usage stratégique engage le niveau de risque accepté par l’entreprise, ses priorités et parfois son modèle opérationnel. Ce n’est pas un simple arbitrage technique.

Une DSI qui refuse tout devient un obstacle. Une DSI qui accepte tout devient le paratonnerre des erreurs métier.

Dans les deux cas, l’organisation évite la question décisive : qui décide, qui assume et qui change réellement sa manière de travailler ?

Ce que les métiers doivent cesser de déléguer

Les métiers ne peuvent pas demander les bénéfices de l’IA tout en déléguant à la DSI les décisions qui donnent un sens à son usage.

Partir d’un problème, pas d’un outil

« Pouvez-vous nous installer un outil d’IA ? » ne permet pas de piloter un projet sérieux.

Une demande plus utile serait :

« Nous consacrons aujourd’hui 40 heures par semaine à qualifier ces demandes. Voici les étapes, les erreurs fréquentes, les données disponibles et le niveau de risque acceptable. Peut-on améliorer ce processus ? »

La différence est majeure.

Dans le premier cas, l’outil devient le point de départ. Dans le second, le processus et ses résultats deviennent l’objet du travail.

Cette approche peut même révéler qu’un projet IA n’est pas nécessaire. Il suffit parfois de supprimer une validation redondante, de clarifier une règle ou de réunir des informations déjà dispersées dans plusieurs systèmes.

C’est moins spectaculaire qu’un nouvel assistant. C’est souvent plus efficace.

Définir ce qu’est une bonne réponse

Les métiers doivent préciser :

• les résultats attendus ;
• les erreurs inacceptables ;
• les exceptions fréquentes ;
• les documents faisant autorité ;
• les situations nécessitant une validation humaine ;
• les indicateurs de performance.

Une IA ne peut pas compenser l’absence de définition claire de la qualité.

Si deux managers ne sont pas d’accord sur ce qu’est une bonne réponse, un modèle plus puissant ne résoudra pas le problème. Il produira simplement des réponses plus rapides dans un cadre toujours indécis.

Assumer l’usage au quotidien

Le métier doit rester propriétaire du résultat produit dans son périmètre.

La validation technique d’une solution par la DSI ne transfère pas la responsabilité d’une recommandation commerciale, d’une décision RH ou d’une analyse financière.

Automatiser sans responsable ne supprime pas la décision. Cela supprime seulement celui qui devra l’assumer.

Exemple concret : un assistant pour le service client

Une entreprise demande à sa DSI de déployer un assistant capable de répondre automatiquement aux clients à partir de la base documentaire existante.

La DSI pose les bonnes questions :

• quelles données peuvent être utilisées ;
• où seront hébergées les conversations ;
• comment gérer les accès ;
• comment tracer les réponses ;
• comment superviser les erreurs ;
• quelle solution intégrer au système de relation client.

Mais plusieurs questions restent sans réponse côté métier :

• quelles promesses commerciales l’assistant peut-il formuler ;
• peut-il accorder un geste commercial ;
• que doit-il faire lorsqu’une procédure est ambiguë ;
• quelle version de la documentation fait foi ;
• qui reprend la main lorsqu’un client conteste la réponse ;
• quelle erreur est la plus grave : une réponse trop prudente ou une réponse trop engageante ?

La solution est livrée. Elle est sécurisée. Elle fonctionne.

Pourtant, les réponses s’appuient toujours sur une documentation contradictoire. Les conseillers ne savent pas quand corriger l’assistant. Les managers ne définissent aucun indicateur de qualité.

Au bout de quelques semaines, l’entreprise mesure le nombre de conversations traitées. Elle constate même une hausse de l’activité automatisée.

Mais les réclamations augmentent. Les dossiers complexes sont transférés aux conseillers. La charge ne disparaît pas : elle se déplace, souvent vers les situations les plus difficiles.

Le problème n’était pas l’absence d’assistant.

C’était l’absence de règles métier stabilisées.

Le projet aurait dû réunir le service client, propriétaire du processus, la DSI, le juridique, la conformité, la sécurité et les utilisateurs de terrain.

Chacun aurait eu une contribution distincte :

• le service client définit les objectifs, les règles et les exceptions ;
• la DSI sécurise les données et l’intégration ;
• le juridique encadre les engagements et les informations sensibles ;
• les utilisateurs testent les cas réels ;
• la direction arbitre le niveau de risque acceptable.

Elle évite surtout d’industrialiser une ambiguïté.

Les mêmes limites apparaissent ailleurs

Dans les ressources humaines, une entreprise peut demander un outil de présélection des CV. La DSI contrôlera les accès et l’intégration avec le système de recrutement. Mais elle ne peut pas décider seule quels critères sont pertinents, quels biais sont inacceptables ni quand un recruteur doit vérifier la recommandation.

Dans la finance ou les achats, la DSI peut intégrer un outil de lecture automatique des factures. Le métier doit alors définir les seuils de contrôle, les anomalies bloquantes, les fournisseurs sensibles et les cas nécessitant une validation manuelle.

Dans une PME, la direction peut interdire tous les outils d’IA par peur d’une fuite de données. Pendant ce temps, les équipes utilisent déjà des solutions personnelles.

Quand l’entreprise interdit les usages sans les gouverner, elle ne les arrête pas. Elle les pousse hors de son regard.

Une responsabilité distribuée, une décision assumée

Une transformation IA crédible repose sur une responsabilité distribuée — pas sur une responsabilité diluée.

La direction générale

Elle doit :

• définir l’ambition ;
• arbitrer les priorités ;
• accepter ou refuser certains risques ;
• imposer la coopération entre fonctions ;
• éviter la prolifération de pilotes isolés ;
• demander des résultats liés à la performance réelle.

Le rôle de la direction n’est pas de demander « de l’IA » à la DSI. C’est de décider quels changements l’entreprise est prête à conduire.

Les métiers

Ils doivent :

• identifier les processus à améliorer ;
• qualifier les données et les exceptions ;
• définir les règles de validation ;
• tester les résultats ;
• former les utilisateurs ;
• assumer la responsabilité opérationnelle.

Un métier spectateur ne devient pas propriétaire d’un usage par simple signature en fin de projet.

La DSI

Elle doit :

• construire le cadre technique ;
• sécuriser les données et les intégrations ;
• rendre les usages observables ;
• éviter la multiplication des outils ;
• accompagner l’industrialisation ;
• alerter lorsque les conditions de fiabilité ne sont pas réunies.

Elle n’est ni un guichet de refus ni un fournisseur interne de prototypes. Elle est l’architecte des conditions de déploiement.

Les fonctions de contrôle

Le juridique, la conformité, la gestion des risques et la sécurité doivent intervenir en amont, pas uniquement au dernier moment pour bloquer le projet.

Ils contribuent à définir les usages acceptables, les niveaux de preuve, les exigences de traçabilité, les catégories de données à protéger et les conditions de supervision humaine.

Trois symptômes d’une transformation IA mal gouvernée

1. La DSI reçoit toutes les demandes, mais aucune priorité claire

Chaque métier arrive avec son outil préféré. Les projets sont évalués selon leur nouveauté plutôt que selon leur contribution à la performance, à la qualité du travail ou à la satisfaction client.

La DSI devient alors un catalogue, un filtre et un service après-vente. Ce n’est pas une stratégie de transformation.

2. Les métiers veulent les bénéfices sans prendre les décisions difficiles

Ils demandent une automatisation, mais refusent de supprimer les doublons, de clarifier les règles ou de revoir les étapes du processus.

L’IA devient une surcouche de compensation : elle masque temporairement le désordre sans le corriger.

3. L’entreprise mesure l’adoption au lieu de mesurer le changement

On compte les licences, les utilisateurs, les prompts et les prototypes.

On mesure moins souvent :

• le temps réellement économisé ;
• les erreurs évitées ;
• les décisions améliorées ;
• la qualité de service ;
• la charge déplacée vers les équipes ;
• la responsabilité effectivement assumée.

Une entreprise ne se transforme pas parce qu’elle lance des pilotes. Elle se transforme lorsque ses décisions, ses délais et ses responsabilités changent.

Une méthode simple pour sortir des malentendus

Une matrice de responsabilité suffit souvent à révéler les zones floues :

| Question | Responsable principal | Contribution de la DSI |<br>|---|---|---|<br>| Quel problème veut-on résoudre ? | Métier | Évaluation de la faisabilité |<br>| Quel risque l’entreprise accepte-t-elle ? | Direction générale et fonctions de contrôle | Analyse des risques techniques |<br>| Quelle solution peut être déployée ? | DSI | Pilotage technique |<br>| Qui valide le résultat au quotidien ? | Métier | Traçabilité et supervision |

Un comité de gouvernance IA peut arbitrer les cas d’usage, à condition de disposer d’un véritable pouvoir de décision.

Un comité sans critères explicites, sans responsable nommé et sans pouvoir d’arrêt n’est pas une gouvernance. C’est un espace de discussion supplémentaire.

Avant de passer du prototype au processus, il faut pouvoir répondre à sept questions :

1. Le problème métier est-il précisément formulé ?<br>2. Le processus a-t-il été décrit avant d’être automatisé ?<br>3. Les données utilisées sont-elles fiables et légitimes ?<br>4. Les erreurs acceptables sont-elles définies ?<br>5. Un responsable métier est-il nommé ?<br>6. Les utilisateurs savent-ils quand intervenir ?<br>7. L’impact est-il mesuré autrement que par l’usage de l’outil ?

Ces questions ne constituent pas une procédure de plus. Elles forment un test de maturité organisationnelle.

À retenir

• La DSI peut sécuriser, intégrer et superviser une solution. Elle ne peut pas définir seule sa valeur métier.
• Un cas d’usage IA commence par un problème de processus, pas par une licence ou une plateforme.
• Les métiers doivent définir la qualité attendue, les exceptions et les règles de validation.
• La direction générale doit arbitrer les priorités et le niveau de risque acceptable.
• Une gouvernance efficace désigne qui décide, qui valide et qui répond du résultat.
• L’absence de cadre ne supprime pas les usages : elle pousse les pratiques hors du contrôle collectif.
• La transformation se mesure aux décisions et aux résultats améliorés, pas au nombre de pilotes lancés.

La question à poser en comité

Si cet usage IA produit une erreur demain, qui a le pouvoir de l’arrêter — et qui devra répondre de ses conséquences ?

Si la réponse reste vague, le projet n’est probablement pas prêt à être industrialisé.

La DSI ne peut pas porter seule la transformation IA, parce qu’elle ne peut pas décider seule de ce que l’entreprise accepte de changer.

Elle peut sécuriser les données, intégrer les outils, rendre les usages observables et arrêter une solution dangereuse. Elle ne peut pas définir à la place des métiers ce qu’est une bonne décision, une erreur acceptable ou une responsabilité assumée.

La transformation commence lorsque la direction arbitre, lorsque les métiers deviennent propriétaires des résultats et lorsque la DSI cesse d’être le guichet auquel chacun dépose ses ambiguïtés.

La question n’est donc pas seulement :

« Quelle IA devons-nous déployer ? »

C’est plutôt :

« Quel processus sommes-nous prêts à revoir, quelle décision sommes-nous prêts à encadrer et qui répondra du résultat ? »

Si personne ne peut répondre, le problème n’est pas encore technologique. Il est organisationnel.

C’est ce déplacement du regard qu’explore La couche IA : non pas comment ajouter une intelligence à l’entreprise, mais ce que l’entreprise doit clarifier avant de prétendre en tirer parti.

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