L’IA n’est pas un sujet DSI

Le réflexe

Un sujet nouveau arrive avec un clavier : direction la DSI. La logique semble imparable — c’est de la technologie, donc c’est de la technique.

Le raisonnement a fonctionné pour la messagerie, le réseau, la téléphonie. Il échoue pour l’IA, et l’écart n’est pas marginal : il est structurel.

La messagerie transporte vos messages sans les comprendre. L’IA, elle, exécute vos raisonnements. Elle décide, trie, formule, priorise — des actes de métier, pas des actes d’infrastructure.

Confier vos raisonnements à ceux qui gèrent vos serveurs, c’est demander au garagiste de choisir vos itinéraires.

Ce que la DSI sait faire — et ce qu’elle ne peut pas savoir

Disons-le clairement : le problème n’est pas la compétence de vos équipes informatiques. Elles font tenir debout ce que tout le monde utilise, avec des moyens comptés.

Le problème est ailleurs : les règles qui font gagner de l’argent ne sont pas dans leurs murs.

La DSI sait déployer un modèle. Elle ne peut pas savoir qu’une remise au-delà de 12 % détruit la marge sur la gamme B. Elle sait connecter une API. Elle ne peut pas savoir qu’un devis pour l’export exige une clause particulière depuis le litige de 2022. Elle sait sécuriser un accès. Elle ne peut pas savoir quel client mérite un appel plutôt qu’un email.

Ces règles constituent l’essentiel de la valeur d’un système IA. Elles n’ont jamais été documentées, car personne n’en avait besoin : elles vivaient dans les têtes.

Un projet IA piloté par la seule DSI produit donc, en toute logique, un système techniquement propre et commercialement vide. L’infrastructure est là. Le métier n’y est pas.

Où vivent les règles

Faites l’exercice. Prenez votre meilleur vendeur, votre meilleur acheteur, votre responsable ADV la plus expérimentée. Demandez-leur pourquoi ils ont pris leurs trois dernières décisions.

Vous entendrez des règles précises, conditionnelles, truffées d’exceptions — un savoir opérationnel d’une densité remarquable, qui ne figure dans aucun manuel de procédures.

C’est cela, la matière première d’un Skill : une compétence métier extraite, formalisée, encapsulée. Et cette extraction est un travail de dialogue avec le métier, pas un chantier d’infrastructure.

Le métier détient les règles. Lui seul peut dire ce que le système doit faire, où il doit s’arrêter, et ce qu’un bon résultat veut dire.

Le bon partage des rôles

La conclusion n’est pas d’écarter la DSI. C’est de remettre chacun à sa place dans l’attelage.

Le métier décide. Il choisit le flux à équiper, fournit les règles, fixe les seuils, valide les sorties. Il est propriétaire du système et de son indicateur de résultat.

La DSI sécurise. Accès, données, conformité, intégration aux systèmes existants. Un rôle exigeant, critique — et distinct.

L’ingénierie d’attelage relie les deux. Le Harness Engineering transforme les règles du métier en Skills exécutables, les branche sur les outils qu’administre la DSI, et pose les instruments de mesure que lira la direction.

Quand ce triangle est respecté, le projet avance vite : chacun parle de ce qu’il connaît. Quand il est écrasé sur un seul sommet, le projet devient soit un gadget technique, soit un vœu métier sans exécution.

La question à poser lundi

Qui, dans votre organisation, est propriétaire de votre prochain système IA ?

Si la réponse est un nom de la DSI seul : arrêtez-vous. Si la réponse est « personne » : arrêtez-vous aussi. Si la réponse est un responsable métier, flanqué de la DSI et outillé pour mesurer : vous avez une chance sérieuse.

Ce qu’il faut en retenir

L’IA exécute des raisonnements de métier. Sa gouvernance appartient donc au métier — la DSI sécurise, l’ingénierie attelle.

C’est le cœur de notre approche : extraire les Skills là où ils vivent, les atteler proprement avec le Harness Engineering, et rendre le résultat mesurable en euros pour la direction.