Comment l’IT a contribué à amplifier les promesses de l’IA

Le recul du scepticisme de l’IT d’entreprise alimente le battage autour de l’IA

Pendant des décennies, les responsables IT seniors avaient un rôle clair. Ils confrontaient les promesses des fournisseurs à la réalité technique. Les fournisseurs pouvaient promettre des gains majeurs, mais les équipes IT devaient encore établir si la technologie fonctionnait, si elle était sécurisée et si elle résolvait un véritable problème métier.

L’IA a changé ce modèle de gouvernance. Les PDG, les DAF et les conseils d’administration sont désormais directement impliqués dans les décisions technologiques. Leur attention peut accélérer l’investissement et le déploiement. Elle crée aussi une incitation difficile à gérer lorsque des dirigeants s’engagent en faveur d’une technologie avant que la validation technique ne soit terminée.

La véritable contrainte est l’indépendance organisationnelle. Un responsable IT peut contester un fournisseur avec un coût politique limité. Contester un PDG qui a déjà validé une stratégie IA est plus difficile. Un désaccord technique peut devenir une question de jugement de la direction, de risque de carrière et de politique interne. Les responsables IT peuvent réagir en atténuant leurs évaluations ou en acceptant des hypothèses qu’ils auraient autrement testées de manière plus rigoureuse.

C’est important parce qu’une gouvernance de l’IA efficace dépend d’un examen technique indépendant. Les entreprises ont besoin de personnes ayant suffisamment d’autorité pour poser des questions élémentaires : quel problème ce système résout-il ? Quels éléments étayent l’affirmation de performance ? Comment échoue-t-il ? À quelles données peut-il accéder ? Que se passe-t-il lorsque son résultat est erroné ? Qui peut l’arrêter ?

Les dirigeants devraient considérer ces questions comme faisant partie du processus d’investissement. Une remise en question technique solide améliore l’adoption de l’IA, car elle aide les entreprises à orienter leurs capitaux vers des systèmes capables de résister à un examen opérationnel, sécuritaire et financier.

Le « hypegineering » peut faire passer le marketing de l’IA avant les capacités techniques

Ralph Aboujaoude Diaz, Global Head of GRC chez Haleon, entreprise britannique de santé grand public, et auparavant professionnel de la cybersécurité des opérations chez Philip Morris, décrit ce problème comme du « hypegineering ». Dans son post LinkedIn, il l’a défini comme le moment où le « marketing devient plus innovant que la technologie elle-même » en matière d’IA.

Diaz a également identifié les conséquences métier. Il a écrit que les « effets secondaires » potentiels incluent le fait de « croire qu’une technologie médiocre est révolutionnaire, confondre battage et progrès, acheter des solutions à des problèmes que vous n’avez pas et les défendre comme si votre poste en dépendait ».

Ces risques renvoient à un problème fondamental d’achats. La terminologie de l’IA peut faire paraître des capacités familières comme fondamentalement nouvelles. Des termes comme « agentique », « autonome » et « propulsé par l’IA » apportent peu de valeur décisionnelle à moins qu’une entreprise ne les relie à des capacités mesurables, à des limites et à des résultats métier.

Les dirigeants devraient donc partir du besoin métier. Définissez le problème, le résultat attendu, les taux d’échec acceptables, les limites de sécurité et le seuil financier de déploiement. Testez ensuite le produit au regard de ces exigences. Cette séquence réduit le risque qu’un produit séduisant crée son propre business case une fois que la direction s’est déjà intéressée à son achat.

La même discipline s’applique aux affirmations sur la sécurité de l’IA. Le fait qu’un fournisseur qualifie un contrôle de « guardrail » ne prouve pas que ce contrôle est fiable. Pour un agent IA capable d’agir, les dirigeants doivent comprendre quelles autorisations sont techniquement appliquées, à quelles données le système peut accéder, comment des instructions peuvent modifier son comportement et quels dommages une défaillance pourrait causer.

L’IA peut malgré tout générer des gains d’efficacité significatifs. La qualité de l’investissement dépend de la capacité à distinguer les capacités démontrées du langage marketing. Pour la direction générale, cela signifie exiger des preuves avant de s’engager et donner aux équipes techniques suffisamment d’indépendance pour remettre en cause les hypothèses avant qu’elles ne deviennent une stratégie d’entreprise.

Des droits de décision clairs donnaient autrefois à l’IT plus de liberté pour tester les promesses technologiques

La gouvernance technologique en entreprise reposait autrefois sur une répartition des responsabilités plus simple. Les PDG, les DAF et les conseils d’administration se concentraient sur les résultats métier. Les équipes IT seniors évaluaient le fonctionnement de la technologie, ses points de défaillance potentiels et la capacité des promesses fournisseurs à résister à un examen technique.

Cette structure donnait aux responsables IT la marge nécessaire pour contester les fournisseurs. Des technologies comme la RFID, la NFC et la biométrie ont traversé des cycles de forte promotion par les fournisseurs. Les équipes IT pouvaient remettre en question ces affirmations sans contester directement une position stratégique déjà adoptée par la direction.

L’IA a modifié la structure de décision. Les PDG et les conseils d’administration participent de plus en plus à la stratégie IA parce que cette technologie peut affecter la productivité, les modèles opérationnels, l’expérience client, la sécurité et le positionnement concurrentiel. Une implication plus forte de la direction peut accélérer les décisions. Elle signifie aussi que les évaluations techniques peuvent avoir des conséquences politiques lorsqu’elles entrent en conflit avec un engagement pris par un dirigeant.

Pour la direction générale, la question clé est celle des droits de décision. La direction exécutive doit définir les objectifs stratégiques, les limites d’investissement, le niveau de risque acceptable et les résultats métier attendus. Les responsables techniques doivent disposer d’une autorité claire pour valider l’architecture, la sécurité, la fiabilité, l’accès aux données et la faisabilité opérationnelle. Les équipes achats et métier doivent ensuite vérifier si l’économie du projet justifie le déploiement.

Ce modèle exige toujours que les dirigeants comprennent l’IA. Une supervision efficace dépend d’un niveau de connaissance technique suffisant pour poser des questions rigoureuses tout en préservant une revue technique indépendante. Un PDG n’a pas besoin de déterminer si un contrôle système spécifique fonctionne. Le PDG a besoin de preuves que des équipes qualifiées ont testé ce contrôle avant d’approuver une exposition significative.

Une gouvernance solide dépend donc d’un désaccord constructif. Une objection technique devrait déclencher une investigation et la production de preuves. Donner à l’IT la possibilité de remettre en cause les hypothèses peut révéler tôt les faiblesses des projets et renforcer les projets prometteurs avant que des capitaux, des données ou la réputation ne soient exposés à un risque important.

L’engagement de la direction en faveur de l’IA peut faire du désaccord technique un risque de carrière

La gouvernance de l’IA s’affaiblit lorsque le désaccord technique entraîne des conséquences personnelles. Un responsable IT peut rejeter une affirmation exagérée d’un fournisseur dans le cadre d’un processus d’achat normal. La situation change dès lors qu’un PDG, un DAF ou un membre du conseil d’administration a publiquement soutenu la technologie ou l’a liée à une initiative stratégique.

À partir de ce moment, une critique technique peut implicitement remettre en cause une décision de la direction. Les responsables IT peuvent subir une pression pour atténuer les évaluations de risque, employer un langage plus favorable ou trouver des moyens de soutenir une décision qui, dans les faits, a déjà été prise. La contrainte immédiate est organisationnelle : les personnes chargées d’identifier le risque technique peuvent dépendre de celles dont elles doivent contester les hypothèses.

L’IA agentique rend ce problème particulièrement important. Ces systèmes peuvent exécuter des tâches et entreprendre des actions avec des niveaux d’autonomie variables. Un dirigeant senior peut entendre qu’un agent dispose de « guardrails » et interpréter ce terme comme la preuve d’un contrôle fiable. Les équipes techniques doivent toujours déterminer si ces contrôles peuvent réellement empêcher des actions interdites, résister à des prompts hostiles, restreindre l’accès à des informations sensibles et contenir les défaillances.

Les dirigeants peuvent réduire cette tension par la conception de la gouvernance. Les déploiements d’IA significatifs devraient avoir des critères d’approbation explicites, des constats de risque documentés, des responsables désignés et une autorité claire permettant aux responsables sécurité ou technologie de retarder le déploiement lorsque des contrôles critiques échouent. Ces mécanismes transforment le désaccord en une partie définie du processus de décision.

Le comportement de la direction compte aussi. Les PDG et les conseils d’administration devraient valoriser l’identification précoce des faiblesses. Une équipe qui découvre une faille grave avant le déploiement a créé de la valeur métier. La direction peut alors corriger le contrôle, modifier le périmètre, sélectionner un autre produit ou arrêter l’investissement avant que le risque ne devienne un problème opérationnel.

L’adoption de l’IA bénéficie de l’association entre ambition de la direction et scepticisme technique. Le senior management fixe l’objectif métier et établit le niveau de risque acceptable. L’IT valide si le système proposé peut fonctionner dans ces limites. Préserver cette séparation donne aux dirigeants de meilleures informations et crée une base plus solide pour déployer l’IA à grande échelle.

L’IA agentique met en évidence l’écart entre l’autonomie promise et un contrôle fiable

L’IA agentique augmente les enjeux de la gouvernance de l’IA parce que ces systèmes peuvent agir. Selon leurs autorisations, les agents peuvent récupérer des informations, utiliser des outils logiciels, modifier des enregistrements, envoyer des messages, lancer des workflows ou interagir avec d’autres systèmes. Chaque autorisation supplémentaire augmente l’impact potentiel d’une action incorrecte ou manipulée.

Cela rend le mot « guardrail » important. Un guardrail peut désigner des instructions, des filtres de contenu, des contrôles d’autorisation, des vérifications de validation ou d’autres mécanismes conçus pour contraindre un système d’IA. Ces contrôles diffèrent fortement en robustesse. Les dirigeants doivent savoir quelles restrictions sont techniquement appliquées et lesquelles dépendent du fait que le modèle suive les instructions de manière constante.

Les prompts constituent une préoccupation particulière. Des utilisateurs, des contenus externes ou des attaquants peuvent fournir des instructions qui influencent le comportement du modèle. Pour un système autonome, un comportement inattendu peut conduire directement à une action. Le risque pertinent dépend donc de ce à quoi l’agent peut accéder, de ce qu’il peut exécuter et du niveau d’approbation humaine requis avant que des opérations conséquentes n’aient lieu.

L’accès aux données mérite le même niveau d’examen. Un agent connecté à des référentiels internes peut rencontrer des dossiers financiers, de la propriété intellectuelle, des informations clients, des identifiants ou d’autres données sensibles. Des autorisations étendues peuvent amplifier les conséquences d’un système compromis ou mal contrôlé. Les promesses d’une efficacité accrue doivent donc être évaluées en parallèle du coût potentiel d’une divulgation ou d’une action non autorisée.

La direction générale devrait exiger des réponses concrètes avant d’approuver une IA agentique. Quelles actions l’agent peut-il effectuer ? À quels systèmes peut-il accéder ? Comment les autorisations sont-elles appliquées ? Quelles actions nécessitent une approbation humaine ? L’entreprise peut-elle inspecter ce que l’agent a fait et pourquoi ? Quel mécanisme coupe immédiatement l’accès lorsqu’un comportement anormal apparaît ?

L’IA autonome peut apporter des gains de productivité utiles. La qualité du déploiement dépend de contrôles d’ingénierie adaptés aux conséquences d’une défaillance. Une plus grande autonomie exige des autorisations plus strictes, davantage de supervision, de tests, d’auditabilité et de contrôle humain.

L’IT doit rétablir un examen rigoureux de l’IA pendant que les dirigeants rendent le désaccord sans risque

Les entreprises ont besoin d’une méthode disciplinée pour distinguer l’IA utile des affirmations exagérées. Les responsables technologiques seniors sont bien placés pour fournir cet examen, car ils comprennent l’architecture, la sécurité, les flux de données, les dépendances opérationnelles et les limites pratiques des systèmes déployés.

La difficulté centrale est organisationnelle. Rejeter une initiative IA devient politiquement sensible lorsqu’un PDG ou un membre du conseil d’administration l’a déjà soutenue. Une évaluation technique négative peut révéler les faiblesses d’une décision exécutive antérieure. Cette pression peut encourager les équipes à atténuer leurs constats et permettre à des hypothèses fragiles de survivre au processus de revue.

La direction générale peut traiter ce problème par la gouvernance. Les grands programmes d’IA devraient passer des revues techniques, de sécurité, juridiques, financières et opérationnelles définies avant le déploiement. Chaque revue devrait utiliser des critères explicites et produire des constats documentés. Les exceptions à haut risque devraient identifier qui a accepté le risque et pourquoi.

Les équipes techniques ont également besoin d’une autorité à la hauteur de leur responsabilité. Si le DSI, le CISO ou la direction de l’ingénierie est responsable des défaillances liées à l’IA, ces fonctions doivent avoir la capacité de contester les plans de déploiement et de faire remonter les risques non résolus. Les dirigeants devraient s’attendre à de telles contestations pendant le processus d’approbation.

La communication reste importante. Les responsables IT peuvent formuler leurs objections autour des preuves et des conséquences métier. Une évaluation utile identifie l’affirmation non étayée, démontre la limite technique, estime l’impact potentiel et propose une réponse pratique. Cette réponse peut inclure des autorisations plus strictes, une approbation humaine, un déploiement limité, des tests supplémentaires ou une annulation lorsque le risque ne peut pas être maîtrisé.

Cette approche favorise une adoption de l’IA plus rapide et plus durable. Une revue rigoureuse identifie les projets faibles avant qu’ils ne consomment des ressources substantielles. Elle donne aussi aux projets crédibles une base plus solide pour se développer. L’ambition de la direction peut fixer le cap. L’examen technique indépendant détermine si l’organisation peut exécuter cette stratégie dans un niveau de risque acceptable.

Points clés à retenir pour les dirigeants

• Rétablir la fonction de remise en question de l’IT : L’enthousiasme de la direction pour l’IA peut affaiblir l’examen technique indépendant. Donnez aux responsables IT une autorité claire pour tester les affirmations des fournisseurs et remettre en cause les hypothèses avant l’investissement ou le déploiement.
• Tester les affirmations sur l’IA avant de s’engager : Des termes comme « agentique », « autonome » et « propulsé par l’IA » apportent peu de valeur décisionnelle sans preuves. Définissez d’abord le problème métier, le résultat attendu, le taux d’échec acceptable et les exigences de sécurité.
• Établir des droits de décision clairs : Les dirigeants doivent définir la stratégie, les limites d’investissement et la tolérance au risque, tandis que les équipes techniques valident la sécurité, la fiabilité, l’architecture et la faisabilité opérationnelle. Une responsabilité clairement attribuée améliore la qualité des décisions liées à l’IA.
• Rendre le désaccord technique sans risque : La gouvernance de l’IA souffre lorsque contester une initiative crée un risque de carrière. Exigez des revues documentées et donnez aux responsables technologie et sécurité une autorité formelle pour faire remonter les préoccupations non résolues.
• Adapter les contrôles à l’autonomie de l’agent : L’IA agentique peut accéder aux données, utiliser des outils et exécuter des actions. Limitez les autorisations, exigez une approbation humaine pour les actions conséquentes et veillez à ce que la supervision, l’auditabilité et les contrôles d’arrêt correspondent à l’impact potentiel d’une défaillance.
• Faire de l’examen de l’IA une discipline de déploiement : Exigez que les grands projets d’IA passent des revues techniques, de sécurité, juridiques, financières et opérationnelles définies. Une évaluation rigoureuse peut éliminer tôt les projets faibles et donner aux déploiements crédibles une base plus solide pour se développer.