Bâtir l’entreprise axée sur l’AI : pourquoi les modèles opérationnels, et non les modèles, génèrent de la valeur

Le passage à l'échelle de l'AI nécessite de la valeur à laquelle quelqu'un s'engage, une gouvernance conçue avant l'autonomie et un travail repensé autour d'une supervision humaine significative
S'abonner
4 min de lecture
Dr. Paul Yu-Chun Chang
Dr. Paul Yu-Chun Chang
Senior AI Technical Architect and Strategy Consultant, HCLTech
4 min de lecture
Créer l’entreprise axée sur l’AI : pourquoi les modèles opérationnels, et non les modèles, génèrent de la valeur

La plupart des entreprises ont adopté l’AI. Bien moins nombreuses sont celles qui ont appris à l’exploiter à grande échelle. Ce fossé — et non la technologie — empêche bon nombre d’initiatives prometteuses de générer de la valeur à l’échelle de l’entreprise.

Selon une étude de Gartner publiée en septembre 2026, seulement 22 % des organisations ont réussi à déployer l’AI à grande échelle dans plusieurs unités d’affaires ou à adopter une approche axée sur l’AI, alors même que 85 % des leaders fonctionnels prévoyaient augmenter leurs investissements en AI en 2026. Le défi va au-delà des capacités des modèles. En pratique, les tableaux de bord affichent du vert, mais le P&L reste inchangé et des agents qui réussissent tous les tests échouent en production.

La différence tient au modèle opérationnel : qui est responsable du résultat, quelle valeur est attendue et comment la préparation, le risque et la réutilisation orientent l’investissement. L’assistant AI d’une fintech européenne a géré deux tiers de ses discussions de service à la clientèle dès son premier mois, mais le PDG de l’entreprise a ensuite reconnu que le coût avait été « un facteur d’évaluation trop prédominant ». À mon avis, cela illustre comment un assistant AI peut être performant à grande échelle, alors que le modèle opérationnel autour ne parvient pas à équilibrer économies de coûts et qualité du service.

Là où les ambitions AI se heurtent à la réalité

Dans l’industrie, je remarque trois sources de désillusion récurrentes : la valeur, le contrôle et l’échelle. Aucune ne transparaît dans une démo.

La valeur est perdue lorsque les équipes mesurent l’activité plutôt que les résultats. Tableaux de bord verts, dossiers clôturés et agents « en ligne » peuvent coexister sans apporter de bénéfice financier, surtout si les anciens processus d’approbation et files d’exception subsistent. C’est pourquoi un résultat d’affaires avec une personne responsable et validé par des experts doit faire partie des critères de mise en production de l’AI.

Le contrôle est la deuxième dimension. Les garde-fous sont essentiels, mais s’ils se limitent à des interdictions, ils bloquent des tâches utiles ou les enfouissent sous des approbations. Les droits de décision comptent tout autant : quand l’AI, les règles existantes et les humains examinent le même dossier, personne ne porte la responsabilité du résultat. Un taux élevé de réussite aux tests peut masquer des échecs sur la formulation réelle des utilisateurs si des règles codées en dur priment sur l’interprétation du modèle. Ma règle : les systèmes détiennent les faits et les limites ; l’AI exerce son jugement à l’intérieur de ces paramètres.

Viennent ensuite les contraintes de l’échelle. Les données d’entreprise peuvent faillir sans bruit et l’AI traduit ces erreurs en actions. Les quotas de passerelle, les délais d’attente et les coûts décident souvent de l’issue avant même que le modèle n’entre en jeu : un modèle plus volumineux ne donne pas automatiquement de meilleurs résultats si les délais et limites ont été conçus pour un modèle plus petit. Il faut d’abord corriger l’infrastructure avant de comparer les modèles.

Gouvernance avant autonomie

La priorité est de relier à la valeur grâce à des critères d’évaluation et de mise en production clairs. Il faut traiter l’évaluation comme un produit gouverné, avec un seuil de qualité fixe et un évaluateur d’AI désigné, plutôt que des cibles mouvantes tout au long du développement. Des cibles instables, et c’est là que les agents « s’emballent ».

Cette base rend l’autonomie sécuritaire. Je la conçois comme une échelle d’autonomie : assisté, recommander, agir avec approbation, agir dans les limites. Les agents montent un échelon à la fois, par décision, seulement si les contrôles pour cet échelon existent. L’autonomie se mérite, elle ne s’installe pas.

La gouvernance doit permettre un travail utile en toute sécurité. Si chaque action de routine attend une intervention humaine, les avantages de la rapidité des agents disparaissent. À l’inverse, retirer la supervision sans une évaluation fiable crée des risques qui n’apparaîtront qu’après le déploiement.

Définir ces frontières d’avance coûte bien moins cher que de modifier les exigences une fois les agents en service.

Refaire la tâche, y compris le rôle humain

illustre bien comment la nature du travail évolue. Autrefois, les développeurs cherchaient sur Stack Overflow, trouvaient des exemples et écrivaient le code manuellement. Aujourd’hui, un peut générer des milliers de lignes en quelques minutes.

Le goulot d’étranglement est passé de l’écriture au jugement. Un évaluateur AI peut aider, mais il peut aussi laisser passer des faiblesses. Les humains doivent encore posséder l’expérience pour questionner ce que produisent les agents.

J’en ai fait l’expérience. Un agent AI a déjà proposé un changement bien plus important que nécessaire. Lorsque j’ai remis en question son plan et suggéré une approche plus simple, il a révisé sa solution et l’effort estimé a chuté considérablement.

C’est la refonte de la tâche appliquée : les agents produisent, les humains établissent le standard, contestent le plan et décident de s’arrêter. La capacité de supervision doit être planifiée comme toute autre ressource, sinon la génération plus rapide ne fait qu’accroître la file d’attente de travail à vérifier.

Établir la base, puis passer à l’échelle

Chaque entreprise possède ses propres architectures, données et contraintes, mais l’ordre de construction demeure : d’abord la création de valeur et son responsable, puis les données et l’évaluation, ensuite la structure AI avec passerelle, quotas, observabilité et contrôle des coûts, et seulement après, l’autonomie élargie. Il faut connaître les limites de la plateforme avant le déploiement, et non les découvrir lors des correctifs.

Pour détecter ce qui limite votre programme, mesurez-vous face aux briseurs de rêves; le pointage le plus bas indique la limite. Faible en valeur, augmenter la dépense est prématuré. Faible en contrôle, donner plus d’autonomie est prématuré. Faible en supervision, plus d’agents vous ralentiront. Chez HCLTech, nous passons à travers ce processus côte à côte avec les équipes techniques, sur leur infrastructure réelle.

Ce novembre, plus de 6 500 CIO et leaders du secteur se réuniront au Gartner IT Symposium/Xpo™ 2026 à Barcelone pour explorer les priorités qui façonnent l’avenir des technologies d’entreprise. J’ai hâte de contribuer à cette discussion en examinant les huit briseurs de rêves qui se répètent dans les programmes AI d’entreprise et de partager comment les organisations peuvent identifier ce qui les empêche d’atteindre une réelle valeur d’affaires mesurable.

Une question à ramener à votre équipe : si les agents produisaient dix fois plus de travail le trimestre prochain, qui le vérifierait et qui pourrait décider de stopper? L’AI fait désormais partie de la base. Le modèle opérationnel, c’est ce que vous bâtissez dessus.

Participez à ma séance, HCLTech : Bâtir l’entreprise AI — un modèle opérationnel pour l’AI à l’échelle, le lundi 9 novembre à 15 h 35 (heure d’Europe centrale).

Inscrivez-vous à la séance ou .

Partager
GÉO Europe et Afrique Article Bâtir l’entreprise axée sur l’AI : pourquoi les modèles opérationnels, et non les modèles, génèrent de la valeur