Les annonces de recrutement autour de l’IA se multiplient. On recherche des ingénieurs expérimentés en architecture IT, capables de piloter des développeurs, mais aussi de comprendre les métiers, d’assurer l’avant-vente et parfois de définir la stratégie produit. Je ne compte plus les annonces pour des profils hybrides de CTO, CPO ou Head of AI sur LinkedIn. À l’inverse, on recherche des AI Champions dans les métiers, chargés d’en promouvoir les possibilités, mais souvent sans expérience du développement logiciel ni des contraintes techniques associées.

Derrière cette multiplication de profils hybrides se cache une double confusion : la maîtrise de la technologie ne donne pas automatiquement la légitimité à définir une solution métier. Inversement, savoir prototyper avec l’IA ne confère pas une expertise technique. L’IA permet de matérialiser très rapidement une idée, mais ne garantit pas qu’elle réponde à un besoin réel. Sans connaissance du terrain et sans capacité à aller au contact des clients pour comprendre leurs contraintes, on risque surtout de développer plus vite sa propre vision du problème.

Une vieille lutte d’influence entre IT et métiers

La séparation entre maîtrise d’ouvrage et maîtrise d’œuvre a toujours été traversée par des questions de pouvoir. Aujourd’hui encore, architectures existantes, standards internes et feuilles de route saturées peuvent conduire les arbitrages techniques à prendre le pas sur les priorités métiers.

Mais la responsabilité n’est pas uniquement du côté de l’IT. Les métiers lui délèguent parfois la compréhension de leurs besoins ou résistent au changement, échaudés par les vingt précédentes tentatives de refonte. Et lorsqu’ils formulent une demande, ils décrivent souvent une solution connue plutôt que le problème à résoudre. C’est le vieux paradoxe du client qui réclame un cheval plus rapide alors que son besoin est de se déplacer plus rapidement.

Le résultat est familier : des projets techniquement conformes qui ne répondent pas exactement au besoin. Et ce « pas exactement » se traduit par des ressaisies, des fichiers Excel parallèles et des processus manuels qui survivent à la transformation digitale.

Avec l’IA, le risque est de reproduire le même schéma : proposer un chatbot parce que la technologie est disponible, alors que les équipes attendent avant tout un système fiable, des données unifiées ou des processus réellement simplifiés.

L’IA pourrait inverser la logique

L’IA générative permet désormais aux métiers d’aller plus vite, de concevoir et de tester certaines solutions, ou d’outiller des processus auparavant chronophages. Le vibe coding en est une illustration, mais pas une finalité. Il ne s’agit pas de transformer chaque collaborateur en développeur, mais de lui donner les moyens de résoudre davantage de problèmes en autonomie.

Cela suppose de former et d’équiper les métiers : sensibilisation aux coûts et aux risques, outils et environnements approuvés suffisamment sécurisés mais aussi suffisamment ouverts pour permettre l’expérimentation, assistants spécialisés et, lorsque nécessaire, harnais de gouvernance (des ensembles d’outils et de règles qui encadrent le travail avec l’IA, préservent la mémoire des projets et organisent les vérifications). L’objectif est d’éviter de découvrir trop tard des solutions impossibles à industrialiser sans redéveloppement coûteux, alimentant une véritable POC fatigue côté métiers comme IT.

Une équipe chargée de rédiger des contrats pourrait, par exemple, expérimenter des méthodes de travail assistées par IA, en utilisant un harnais pour structurer les échanges entre les différents intervenants, conserver les décisions et vérifier la cohérence des versions successives. Elle pourrait ainsi améliorer sa méthode au fil des dossiers, plutôt que d’attendre le développement d’un outil dont les spécifications auraient été définies en amont, parfois de manière théorique. C’est là que l’IA change la donne : les métiers peuvent expérimenter directement, ajuster leur méthode au fil des usages et rester acteurs de la solution, plutôt que d’exprimer leur besoin une fois pour toutes avant de laisser le projet suivre son cours, qu’il soit rapide ou non.

Un prototype n’est évidemment pas un système de production. Mais plutôt que d’interdire ces initiatives ou de les cantonner à des unités spécialisées, mieux vaut leur donner un cadre accessible à tous. La multiplication des demandes d’approbation d’outils différents risque, à l’inverse, d’encourager le shadow AI, prolongement du shadow IT, avec des risques supplémentaires de confidentialité et de conformité. Combien de collaborateurs utilisent déjà des assistants IA personnels, faute d’accès aux outils approuvés ou dans l’attente d’une autorisation, sans connaître les conditions de traitement des données qu’ils y introduisent ?

Recruter autrement, et former autrement

Dans les services financiers et l’assurance, la connaissance des clients, des processus et des contraintes réglementaires ne s’improvise pas. Un excellent architecte informatique ne devient pas automatiquement un expert de la souscription ou de la gestion des sinistres, et inversement. L’IA donne l’impression de pouvoir tout faire : c’est là le piège.

Je plaide pour le développement d’une fonction d’AI Enablement & Governance, chargée d’accompagner les métiers dans leur montée en compétence, de leur fournir des outils adaptés et de rendre compréhensibles les règles de gouvernance et les risques.

Microsoft développe déjà, autour de Power Platform, une approche de Center of Excellence ou Center of Enablement, associant formation, outils, bonnes pratiques et gouvernance pour permettre aux équipes de créer des solutions tout en conservant des standards communs. La fonction que je propose s’inscrit dans cette logique, mais au-delà d’une plateforme particulière, en organisant la collaboration entre métiers, IT et fonctions de contrôle.

C’est une fonction hybride, mais pas un nouveau mouton à cinq pattes. Elle doit savoir faire travailler ensemble des spécialistes sans prétendre se substituer à eux. Cela suppose aussi de dépasser certaines baronnies organisationnelles, dont on sait combien elles peuvent peser dans les grandes entreprises.

En parallèle, les équipes IT doivent mieux comprendre les processus métiers, tandis que les métiers et les fonctions juridiques et de conformité doivent acquérir une culture technique suffisante pour intervenir dès la conception, y compris sur les coûts d’utilisation de l’IA, souvent invisibles pour l’utilisateur.

Vers une gouvernance hybride et fédérée

Une gouvernance fédérée ne signifie pas que chacun décide de tout. Elle repose sur des règles communes, des outils partagés et des responsabilités distribuées au plus près des compétences.

Les métiers sont les mieux placés pour identifier les problèmes et évaluer la valeur des solutions, à condition d’être ouverts à d’autres approches. L’IT doit leur fournir les moyens d’expérimenter dans des environnements sécurisés, avec des outils accessibles et une gouvernance intégrant dès la conception les exigences de conformité et de maîtrise des coûts.

Il faut également revoir la manière d’évaluer les projets. Pourquoi continuer à mesurer le succès d’un POC à sa seule réalisation ? Métiers et IT devraient être évalués ensemble sur sa capacité à produire une valeur mesurable et à être industrialisé à un coût maîtrisé, plutôt que de découvrir trop tard qu’une solution est trop coûteuse à exploiter au regard de la valeur réellement créée ou que personne ne l’utilise.

Les métiers doivent pouvoir expérimenter librement dans un cadre défini en amont, avec des outils et des données autorisés et accessibles au plus grand nombre, sans demander une nouvelle permission pour chaque essai. L’IT conserve ses responsabilités d’architecture, de sécurité et d’industrialisation, mais les exerce en facilitant le travail des métiers plutôt qu’en multipliant les validations.

Dans l’assurance, cette articulation est d’autant plus importante que l’AI Act classe certains systèmes d’évaluation des risques et de tarification en assurance vie et santé parmi les usages à haut risque, tandis que DORA renforce les exigences de résilience opérationnelle numérique des acteurs financiers.

Les droits de décision doivent être explicites : les métiers portent la pertinence fonctionnelle, la valeur attendue, la qualité des données fournies et le bon usage des outils ; l’IT garantit les conditions techniques d’exploitation et l’intégration ; les fonctions de contrôle interviennent selon la criticité des risques. Le passage en production repose sur ces responsabilités complémentaires. L’autonomie des métiers n’implique pas qu’ils deviennent responsables de la cybersécurité ou de la maintenance d’applications qu’ils n’ont ni les compétences ni les moyens de garantir.

Les métiers doivent pouvoir optimiser leur propre travail, tandis que la valeur de l’IT se déplace vers sa capacité à les équiper, à transmettre les compétences et à rendre leur autonomie possible sans renoncer à la gouvernance.