Les conclusions d’IDC placent les résultats des projets d’IA sous la surveillance des DSI

Une étude d’IDC a déclenché un débat sur Google News autour de l’échec des projets d’IA, avec un titre affirmant que 45 % des projets ne produisent aucun résultat.

Les éléments sous-jacents exigent une lecture plus attentive. Une étude associée à IDC indique que seulement 45 % des initiatives d’IA produisent en moyenne des résultats mesurables. Cette conclusion laisse entrevoir un écart de valeur plus important que ne le suggère le titre, selon la manière dont les organisations définissent la réussite.

Cette distinction est importante, car les DSI ne sont plus jugés sur le nombre de pilotes d’IA qu’ils lancent. Les conseils d’administration attendent désormais des retours mesurables, des déploiements sécurisés et une gouvernance capable de contrôler les agents autonomes après leur mise en production.

C’est le véritable conflit derrière ce titre. Les dirigeants d’entreprise veulent des systèmes d’IA capables d’accomplir davantage de travail avec plus d’autonomie. Or, cette même autonomie rend plus difficiles à maîtriser les coûts, les décisions, les autorisations et les défaillances.

IDC décrit donc bien plus qu’un nouveau cycle technologique décevant. L’entreprise documente un transfert de responsabilité des équipes d’IA expérimentales vers les DSI, qui doivent défendre les résultats métier et les risques opérationnels.

Ce que dit réellement l’affirmation d’IDC sur Google News

Le chiffre rapporté de 45 % mesure les initiatives produisant des résultats mesurables, et non un taux d’échec universel pour tous les projets d’IA en entreprise.

Le titre original de Google News présente 45 % des projets d’IA comme n’ayant pas produit de résultats. Cependant, les documents complémentaires liés à IDC présentent cette statistique différemment.

Une analyse de Fujitsu cite le Technology Investment and Innovation Monitor d’IDC de septembre 2025. Elle indique que 45 % des initiatives d’IA dans le monde atteignent en moyenne des résultats mesurables.

L’étude a couvert 894 répondants, selon la citation de Fujitsu. Elle a également révélé que seules 11 % des organisations ont déclaré avoir réussi dans plus des trois quarts de leurs projets d’IA.

Ces mesures n’établissent pas que exactement 45 % ont échoué. Elles montrent que 45 % ont produit des résultats mesurables, laissant 55 % sans résultat démontré selon l’approche de mesure de l’enquête.

Cet écart peut recouvrir plusieurs situations. Un projet peut rester en phase de test, atteindre la production sans valeur mesurable, manquer son objectif initial ou ne pas disposer de données suffisantes pour être évalué.

Il s’agit de résultats différents. Les réunir sous un seul taux d’échec produit un titre plus accrocheur, mais une image moins précise de la performance en entreprise.

Les éléments disponibles ne prouvent pas non plus que les modèles d’IA sous-jacents ont causé chaque résultat insuffisant. L’adoption par les métiers, la conception des flux de travail, la qualité des données, les coûts d’exploitation et des indicateurs flous peuvent chacun empêcher la concrétisation de la valeur.

Cette distinction sépare l’échec technique de l’échec organisationnel. Un modèle peut générer une sortie acceptable alors que le projet qui l’entoure manque toujours son objectif métier.

Un assistant interne, par exemple, peut répondre avec précision aux questions des employés. Il échoue néanmoins sur le plan commercial si les salariés l’évitent, si les réponses arrivent trop lentement ou si les coûts de support dépassent les économies réalisées.

Un modèle de prévision peut également bien fonctionner dans des tests contrôlés. Il apporte peu de valeur si les responsables continuent de prendre leurs décisions via un processus plus ancien qui ignore ses recommandations.

Les recherches plus larges d’IDC étayent cette interprétation. Le cabinet indique que les organisations peinent à relier l’expérimentation à des résultats métier mesurables, notamment lorsque les indicateurs de référence n’ont jamais été définis.

C’est pourquoi ce titre mérite d’être examiné sans être écarté. Le pourcentage précis dépend toujours des définitions, mais le problème de valeur sous-jacent est solidement étayé.

D’autres recherches vont dans le même sens. L’enquête 2026 de CIO.com a révélé que seuls 19 % des répondants estimaient que leurs initiatives d’IA avaient atteint ou dépassé les objectifs métier.

L’étude State of the CIO a couvert 662 responsables IT et 249 utilisateurs métier. Elle a constaté que 18 % déclaraient que moins d’un tiers de leurs cas d’usage répondaient aux attentes.

Les études reposent sur des échantillons et des définitions différents ; leurs pourcentages ne doivent donc pas être considérés comme directement comparables. Ensemble, elles montrent que la création de valeur mesurable en entreprise reste peu fréquente.

La conclusion responsable est plus nuancée que l’affirmation virale. De nombreuses organisations ne peuvent pas démontrer des retours constants pour la plupart de leurs initiatives d’IA, et les DSI doivent désormais expliquer pourquoi.

Cette conclusion est suffisamment grave sans étirer le chiffre.

L’expérimentation en IA cède la place à une exigence de ROI

Le changement central n’est pas le recul de l’intérêt pour l’IA. C’est la fin du financement d’expériences sans responsables désignés, références de départ et résultats métier définis.

L’investissement dans l’IA en entreprise se poursuit, même si les retours restent difficiles à prouver. Cette contradiction apparente reflète la pression concurrentielle plutôt qu’une confiance dans chaque projet.

Les conseils d’administration craignent qu’une baisse des investissements ne laisse leurs entreprises à la traîne. Ils veulent aussi que les DSI démontrent que les dépenses existantes améliorent les revenus, les coûts, le service client, la résilience ou la rapidité de décision.

Cela crée une voie plus étroite pour les responsables technologiques. Ils doivent maintenir la dynamique d’adoption tout en mettant fin aux projets incapables de justifier leur charge opérationnelle.

IDC rapporte que 42 % des organisations jugent le ROI des investissements numériques et en IA difficile, voire impossible, à évaluer. Le cabinet identifie des références de départ incohérentes et une visibilité limitée à long terme comme obstacles majeurs.

Son cadre de ROI agentique soutient que les systèmes agentiques aggravent ces problèmes. Leur valeur et leurs coûts évoluent à mesure que les flux de travail, les modèles et les modes d’utilisation changent.

Les logiciels traditionnels s’appuient souvent sur un modèle économique relativement stable. Les acheteurs estiment les coûts d’implémentation, les besoins en licences, les utilisateurs attendus et les gains de processus avant le déploiement.

L’IA agentique fonctionne différemment. Un agent est un logiciel capable de planifier des étapes, d’utiliser des outils et d’agir vers un objectif avec une intervention humaine limitée.

Son coût d’exploitation peut varier selon les appels au modèle, la taille du contexte, l’utilisation des outils, les nouvelles tentatives et les revues humaines. Ses performances peuvent également évoluer lorsque les conditions métier ou les données sources changent.

Un pilote réussi fournit donc des preuves incomplètes. Le pilote peut utiliser des données soigneusement sélectionnées, un petit groupe d’utilisateurs et une supervision technique importante que les équipes de production ne peuvent pas maintenir.

Une fois largement déployé, le même système doit composer avec des entrées incohérentes, des restrictions d’accès, des cas rares et des employés qui l’utilisent de manière inattendue.

Sastry Durvasula, dirigeant chez TIAA, a décrit cette tension dans le rapport de CIO.com. Il a indiqué qu’un pilote réussi peut toujours avoir du mal à générer un ROI réel une fois que les organisations prennent en compte les coûts d’exploitation.

Ces coûts comprennent la consommation de tokens, la gestion du trafic, la maintenance des intégrations, les évaluations, les examens de sécurité et le support. Ils apparaissent rarement dans une démonstration initiale.

La nouvelle mission des DSI commence par la définition de la valeur avant le développement. Un projet doit disposer d’une référence mesurable montrant les performances du processus sans IA.

Il doit également avoir un responsable métier qui bénéficie du résultat. Les équipes techniques ne peuvent pas certifier seules la valeur métier lorsqu’un autre service contrôle l’adoption et les changements de flux de travail.

CIO.com a constaté que 83 % des responsables IT interrogés disposaient de structures d’IA transversales ou prévoyaient de les mettre en place au cours de l’année. Pourtant, l’approbation formelle et la mesure restaient moins matures.

Seules 53 % des organisations disposaient d’un processus officiel d’approbation des projets d’IA. Vingt-huit pour cent supplémentaires prévoyaient d’en introduire un au cours des 12 mois suivants.

Des indicateurs formels existaient dans 47 % des organisations répondantes, tandis que 34 % prévoyaient de les établir. Cet écart aide à expliquer pourquoi les déploiements et les retours mesurables divergent souvent.

Les organisations ne peuvent pas prouver une amélioration si elles n’ont jamais enregistré le coût initial du processus, son taux d’erreur, son délai d’exécution ou le résultat obtenu pour le client.

Il en résulte un renversement de responsabilité. Les premiers programmes d’IA récompensaient le volume de pilotes et l’expérimentation visible. La phase suivante récompense une sélection rigoureuse et une valeur reproductible.

Cette évolution modifie également les conversations avec les fournisseurs. Les affirmations sur la qualité des modèles comptent moins lorsqu’un acheteur ne peut pas relier cette qualité à un résultat opérationnel.

Les DSI ont de plus en plus besoin de preuves sur l’ensemble du flux de travail. Ils doivent mesurer si les employés utilisent le système, si la qualité des sorties reste stable et si les coûts demeurent dans les limites fixées.

Ils ont également besoin d’une règle d’arrêt. Les projets qui échouent de manière répétée à atteindre les seuils d’adoption, de qualité ou de rentabilité doivent perdre leur financement avant de devenir une infrastructure permanente.

Cette pratique ne traduit pas une hostilité envers l’IA. Elle traite les dépenses d’IA avec la même discipline que les autres investissements stratégiques.

Le principal conflit oppose la promesse de l’IA à la réalité opérationnelle

Les projets d’IA en entreprise échouent souvent à la frontière entre une démonstration convaincante et l’environnement complexe où le travail réel s’effectue.

Le principal adversaire de cette histoire n’est pas un fournisseur d’IA face à un autre. C’est la promesse d’une valeur rapide grâce à l’IA face à la réalité des opérations en entreprise.

Les démonstrations isolent généralement une tâche étroite. Les systèmes de production doivent composer avec les autorisations, les enregistrements obsolètes, les politiques contradictoires, les données incomplètes et plusieurs applications interdépendantes.

Chaque dépendance ajoutée crée un nouveau chemin de défaillance. Le modèle peut fournir une réponse raisonnable alors qu’un outil indisponible, un enregistrement obsolète ou une autorisation incorrecte empêche l’action requise.

La qualité des données présente un problème similaire. Les systèmes d’IA peuvent résumer, classer ou récupérer des informations, mais ils ne peuvent pas réparer chaque contradiction cachée dans les référentiels de l’entreprise.

Un agent de support peut rencontrer trois versions d’une même politique de remboursement. Sans source faisant autorité ni historique des versions, il peut sélectionner la mauvaise règle avec assurance.

Le travail intellectuel crée un autre défi de mesure. Rédiger plus vite ne crée pas automatiquement de valeur financière si les employés passent le temps économisé à examiner des sorties peu fiables.

Le projet doit mesurer l’ensemble du processus. Cela inclut la préparation, la génération, la révision, la correction, l’escalade et toute erreur en aval.

C’est là qu’une approche de knowledge blending peut devenir pertinente. La combinaison de sources approuvées et du contexte de travail peut réduire les lacunes de récupération, mais la gouvernance détermine toujours quels éléments sont dignes de confiance.

L’adoption des flux de travail compte également. Les employés contournent souvent un nouveau système lorsqu’il ajoute des étapes, exige des interfaces peu familières ou échoue dans des cas rares.

Ce comportement peut rester invisible pendant un pilote sponsorisé. Les participants reçoivent une formation et un support, tandis que les utilisateurs ordinaires font face à des priorités concurrentes.

Une adoption réussie exige donc une refonte des processus, et non un simple accès à un modèle. Les équipes doivent décider quelles tâches changent, quelles validations restent en place et qui traite les exceptions.

La différence entre assistance et autonomie accroît encore les enjeux. Un assistant de rédaction propose un texte qu’une personne doit examiner. Un agent peut créer des tickets, modifier des enregistrements, contacter des clients ou déclencher des transactions.

Une suggestion inexacte coûte du temps de révision. Une action autonome inexacte peut modifier des systèmes réels avant qu’un humain ne s’en aperçoive.

Les recherches d’IDC soutiennent que les organisations ne devraient pas appliquer la technologie agentique à chaque tâche. L’automatisation déterministe reste plus adaptée aux processus stables régis par des règles claires.

Les systèmes agentiques ont davantage de sens lorsque le travail exige plusieurs étapes, un contexte évolutif, du jugement et une orchestration entre différents outils. Même dans ce cas, l’autonomie doit générer suffisamment de valeur pour justifier le risque supplémentaire.

Cette discipline des cas d’usage aide à expliquer le débat sur l’échec des projets d’IA selon IDC. Certains projets faibles commencent par une technologie à la recherche d’un problème.

Les équipes choisissent d’abord un modèle ou une plateforme d’agents. Elles recherchent ensuite un flux de travail susceptible de justifier l’achat.

Cette séquence produit souvent des prototypes intéressants, mais d’une importance opérationnelle limitée. Aucune unité opérationnelle ne s’approprie le résultat, car le projet ne découle pas d’un besoin mesuré.

Une séquence plus solide commence par un flux de travail coûteux ou contraint. Les équipes établissent son niveau de référence, identifient les décisions concernées et testent si l’IA améliore le résultat global.

La comparaison doit inclure les logiciels conventionnels et les changements de processus. L’IA doit l’emporter parce qu’elle correspond au problème, et non parce que les dirigeants ont demandé une initiative d’IA.

Les organisations doivent également distinguer la productivité de la valeur réellement captée. Faire gagner plusieurs minutes à un employé n’a pas automatiquement de portée financière.

L’entreprise ne capte de la valeur que lorsque ce temps améliore la production, réduit le délai de réponse aux clients, accroît la capacité ou diminue une dépense identifiée.

L’expérience des employés et la résilience peuvent tout de même compter. Toutefois, les dirigeants doivent définir la façon dont ces bénéfices seront mesurés au lieu de les traiter comme des explications commodes après l’échec des objectifs financiers.

IDC propose pour cette raison une cartographie plus large de la valeur. Son cadre inclut la confiance des clients, la résilience, la durabilité et les horizons temporels, en plus des mesures financières conventionnelles.

Ce modèle élargi ne doit pas devenir une excuse pour des affirmations vagues de réussite. Chaque dimension nécessite toujours un responsable, une référence, une méthode de mesure et une date de revue.

La réalité opérationnelle est donc moins spectaculaire qu’un effondrement des modèles, mais plus difficile à corriger. Elle exige une coordination entre les équipes technologiques, financières, de sécurité, juridiques et métiers.

Aucune mise à jour de modèle ne peut créer cette coordination automatiquement.

La gouvernance de l’IA agentique fait de la sécurité une contrainte métier

La gouvernance de l’IA agentique détermine si l’autonomie peut évoluer en toute sécurité, car les agents transforment des résultats incertains en actions dans des systèmes connectés.

La sécurité a toujours influencé les décisions technologiques des entreprises. Les systèmes agentiques changent la donne en combinant l’incertitude des modèles avec des identifiants, des outils, de la mémoire et des accès opérationnels.

Un chatbot classique renvoie généralement des informations. Un agent peut interpréter une demande, élaborer un plan, appeler des applications et continuer à agir après avoir reçu de nouveaux résultats.

Cette capacité élargit la surface d’attaque. Du contenu malveillant peut influencer les instructions d’un agent, tandis que des autorisations excessives peuvent transformer une décision erronée en incident plus grave.

L’injection de prompt en est un exemple. Un attaquant place des instructions dans le contenu lu par le modèle, afin de tenter de détourner le système de sa tâche autorisée.

Le danger augmente lorsqu’un agent peut envoyer des messages, modifier des bases de données, récupérer des dossiers confidentiels ou exécuter du code. Une réponse trompeuse ne devient alors qu’un échec possible parmi d’autres.

IDC met en garde contre les cascades de décisions incontrôlées, les comportements opaques et les escalades fragmentées. Son analyse de gouvernance décrit la gouvernance comme une infrastructure opérationnelle plutôt qu’un examen final de conformité.

Le cabinet prévoit que jusqu’à 20 % des organisations du Global 1000 pourraient faire face à des poursuites, des amendes ou à des évictions de CIO d’ici 2030. IDC relie ce risque à des perturbations très médiatisées causées par une gouvernance insuffisante des agents d’IA.

Il s’agit d’une prévision, et non d’un taux d’échec observé. Elle signale l’ampleur de la responsabilité potentielle plutôt qu’une issue garantie.

IDC recommande la traçabilité, une gouvernance intégrée et des boucles de responsabilité définies. Ces contrôles aident les équipes à reconstituer les décisions et à interrompre les actions avant qu’elles ne franchissent des limites établies.

La traçabilité consiste à enregistrer les données, le modèle, les instructions, les appels d’outils et les résultats impliqués dans une décision autonome. Sans ces enregistrements, les équipes ne peuvent ni enquêter sur les erreurs ni défendre les résultats.

La gouvernance intégrée réunit la sécurité, les données, le juridique, le risque et la responsabilité métier tout au long du cycle de vie du système. Un comité qui n’examine que le modèle ne peut pas gouverner l’ensemble du flux de travail.

Les boucles de responsabilité définissent les moments où une personne doit approuver, examiner ou arrêter une action. Le seuil doit dépendre de la conséquence possible, et non seulement du niveau de confiance du modèle.

Les actions à faible risque peuvent bénéficier d’une autonomie plus large. Envoyer un rappel interne n’entraîne pas les mêmes conséquences qu’approuver un paiement ou modifier le compte d’un client.

Les contrôles d’identité sont tout aussi importants. Chaque agent doit disposer de sa propre identité, de ses autorisations, de son responsable et de sa finalité, plutôt que d’emprunter des identifiants sans restriction à un développeur ou à un service partagé.

Les autorisations doivent respecter le principe du moindre privilège. Un agent ne reçoit que les accès nécessaires au flux de travail qui lui est attribué, sans autorité plus étendue.

Les organisations ont également besoin d’un inventaire fiable. Les équipes de sécurité ne peuvent pas protéger les agents dont elles ignorent l’existence, surtout lorsque les services peuvent les configurer au sein d’applications métier.

L’inventaire doit consigner la propriété, les systèmes connectés, les données approuvées, les fournisseurs de modèles, les résultats des évaluations et les contrôles d’urgence.

Une évaluation continue devient nécessaire après le lancement. Le comportement d’un agent peut changer lorsque les modèles sont mis à jour, que les prompts évoluent, que les outils connectés changent ou que les données métier développent de nouveaux schémas.

IDC note que les performances peuvent se dégrader à mesure que le contexte évolue et que les cas limites s’accumulent. Un agent devient ainsi un service géré en continu plutôt qu’un déploiement achevé.

La sécurité et le ROI convergent donc. La supervision, les évaluations, les contrôles d’accès, la réponse aux incidents et la revue humaine ajoutent tous des coûts opérationnels.

Un dossier commercial qui exclut ces contrôles présente un rendement artificiellement favorable. Les supprimer pour protéger les prévisions transfère la pression financière vers une exposition en matière de sécurité.

C’est le compromis central que les CIO doivent gérer. Une plus grande autonomie peut accroître la vitesse et la capacité, mais elle augmente aussi le coût de l’assurance.

La réponse n’est pas une revue illimitée de chaque action. Elle effacerait l’efficacité qui justifiait l’agent.

Les organisations ont besoin d’une autonomie fondée sur le risque. Elles peuvent automatiser des actions réversibles et observables tout en exigeant une approbation humaine pour les décisions ayant des conséquences juridiques, financières ou de sécurité.

La gouvernance de l’IA agentique doit également couvrir les procédures d’arrêt. Les équipes doivent pouvoir révoquer les identifiants, arrêter les flux de travail, isoler la mémoire et préserver les preuves lors d’un incident.

Sans ces capacités, un agent peut rester opérationnel pendant que plusieurs équipes débattent de la responsabilité. Il s’agit d’un échec du contrôle organisationnel, même si le modèle s’est comporté comme prévu.

Ce que les chiffres ne peuvent toujours pas prouver

Les statistiques disponibles révèlent un vaste problème de création de valeur, mais elles ne permettent pas d’établir un taux d’échec universel pour les projets d’IA.

Le cadrage de Google News encourage une lecture binaire. Un projet réussit ou échoue, un pourcentage unique résumant l’ensemble du marché.

Les déploiements en entreprise correspondent rarement à ce modèle. Un projet peut atteindre un indicateur technique, manquer un objectif d’adoption, respecter son budget et ne produire aucun revenu mesurable.

Un autre projet peut dépasser ses coûts initiaux tout en créant des connaissances stratégiquement importantes ou des bénéfices pour les clients. Le fait qu’il soit considéré comme réussi dépend du cadre d’évaluation.

La formulation des enquêtes modifie également les résultats. « A produit des résultats mesurables » diffère de « a répondu aux attentes », « est entré en production » ou « a généré un rendement financier ».

La sélection de l’échantillon compte aussi. Une enquête auprès de responsables technologiques peut produire des résultats différents d’une étude auprès d’utilisateurs métier, d’équipes financières ou de projets individuels.

Le dénominateur crée un autre problème. Certaines études comptent chaque prototype. D’autres n’incluent que les déploiements en production ou les initiatives connues des dirigeants.

Les horizons temporels diffèrent également. Un système d’IA peut nécessiter plusieurs trimestres de refonte des flux de travail et d’adoption avant que ses bénéfices n’apparaissent.

Le déclarer en échec après un trimestre peut être prématuré. Le poursuivre indéfiniment sans preuves peut gaspiller davantage de capital.

Ces limites n’invalident pas les conclusions d’IDC. Elles définissent ce que les lecteurs peuvent raisonnablement en conclure.

La conclusion la plus solide est que les entreprises peinent à mesurer et à reproduire la valeur de l’IA. La plus faible est qu’un pourcentage fixe de tous les projets a définitivement échoué pour la même raison.

Cette distinction affecte également la responsabilité. Si le modèle est automatiquement mis en cause, les organisations peuvent remplacer les fournisseurs tout en conservant les problèmes de flux de travail, de données et de gouvernance qui ont causé les faibles résultats.

Si chaque problème est imputé à la préparation organisationnelle, les fournisseurs peuvent éviter toute responsabilité pour des produits peu fiables. Les deux récits méritent un examen attentif.

La qualité des modèles reste importante. Les hallucinations, les raisonnements incohérents, la latence, le contexte limité et les erreurs d’utilisation d’outils peuvent rendre une application inadaptée à la production.

La conception des fournisseurs compte également. Les acheteurs ont besoin de journaux d’audit utilisables, de contrôles d’autorisation, de notifications de changement de modèle, d’outils d’évaluation et d’un comportement de service prévisible.

Les organisations restent responsables du choix de cas d’usage appropriés et de la configuration sécurisée des accès. Les fournisseurs restent responsables de la description exacte des capacités et des limites.

La discussion sur l’échec des projets d’IA selon IDC devrait donc susciter de meilleures questions, et non désigner un unique coupable commode.

Quelle référence le projet visait-il à améliorer ? Quel responsable métier a accepté l’objectif ? Les coûts de sécurité et d’exploitation ont-ils été inclus avant l’approbation ?

Les employés ont-ils utilisé le système lorsque le soutien au pilote a pris fin ? La qualité des résultats est-elle restée acceptable face aux cas peu fréquents et à l’évolution des données ?

Les équipes pouvaient-elles reconstituer les actions d’un agent après une erreur ? Pouvaient-elles arrêter immédiatement le flux de travail sans désactiver des systèmes non liés ?

Ces questions transforment un titre contesté en revue opérationnelle. Elles sont aussi plus difficiles à répondre que de savoir si un pilote a été lancé dans les délais.

Une comparaison indépendante renforce la nécessité de prudence. Gartner a indiqué que 45 % des organisations à forte maturité ont maintenu des projets d’IA opérationnels pendant au moins trois ans.

Son enquête sur la maturité de l’IA a associé la longévité à des pratiques matures, mais la longévité seule ne prouve pas la valeur métier.

Un projet peut rester opérationnel pour des raisons stratégiques ou politiques. Un projet peut aussi prendre fin après avoir transféré avec succès sa capacité vers une autre plateforme.

Aucune mesure unique ne saisit l’ensemble du résultat. Les organisations ont besoin d’une vision de portefeuille qui distingue la performance technique, l’adoption, l’impact financier, le risque et la valeur stratégique.

Ce portefeuille doit inclure les projets infructueux. Cacher les pilotes abandonnés donne une image trompeuse et empêche les équipes de reconnaître les causes récurrentes.

Il doit également distinguer une annulation saine d’un échec incontrôlé. Mettre fin tôt à un projet faible peut démontrer une gouvernance disciplinée plutôt qu’une mauvaise performance.

Une source de CIO.com a décrit l’arrêt d’environ un tiers des projets lancés comme une pratique saine. L’organisation utilisait un financement par étapes et des points de contrôle des résultats pour empêcher les travaux faibles de consommer des ressources permanentes.

Cette approche recadre l’échec. Le projet dangereux n’est pas toujours celui qui s’arrête. Cela peut être celui qui continue sans preuves parce que personne ne prend la décision en charge.

Trois signaux que les CIO devraient surveiller ensuite

Le prochain test consistera à voir si les organisations remplacent le décompte des pilotes par le reporting des résultats, une autonomie contrôlée et des preuves que les employés utilisent l’IA dans de véritables flux de travail.

Le premier signal est l’adoption de guides formels de création de valeur par l’IA. IDC prévoit que 60 % des CIO de l’Asia-Pacific 500 seront chargés de les créer d’ici 2027.

Un playbook de création de valeur standardise la sélection des cas d’usage, les références de départ, les modèles de coûts, les responsabilités et les seuils de revue. Il permet aux dirigeants de comparer les projets à partir d’éléments cohérents.

Ce signal renforcerait l’argument d’IDC si les organisations commençaient à arrêter les projets dépourvus de résultats mesurables. Il l’affaiblirait si les mesures formelles se développaient sans améliorer la performance du portefeuille.

L’indicateur clé n’est pas le nombre de playbooks publiés. C’est la part des initiatives en production disposant de responsables désignés, de références de départ, de coûts d’exploitation complets et de revues planifiées des résultats.

Les conseils d’administration devraient également surveiller la manière dont les organisations rendent compte des bénéfices indirects. La confiance des clients, la résilience et des décisions plus rapides peuvent compter, mais chacun exige une méthode de mesure observable.

Le deuxième signal concerne le déploiement de contrôles d’agents applicables. Les politiques seules ne peuvent pas encadrer un logiciel qui agit en continu à travers les systèmes métiers.

Les DSI devraient suivre le nombre d’agents disposant d’identités dédiées, d’autorisations limitées, de journaux d’actions complets, de règles d’escalade humaine et de procédures d’arrêt testées.

Les équipes de sécurité devraient également signaler les incidents par niveau de gravité et cause racine. L’augmentation du nombre d’incidents peut refléter soit une dégradation de la sécurité, soit une meilleure visibilité sur une activité auparavant cachée.

La tendance la plus significative est de savoir si les incidents graves diminuent à mesure que l’usage des agents progresse. Les organisations devraient comparer les taux d’incidents au nombre d’actions des agents, aux systèmes connectés et aux niveaux de risque.

Les perspectives d’IDC pour l’Asie-Pacifique prévoient de graves conséquences en cas de contrôles d’agents insuffisants, notamment une exposition juridique et une responsabilité des dirigeants. Cette prévision devient plus crédible si les déploiements autonomes progressent plus vite que la supervision technique.

Elle devient moins crédible si les organisations démontrent que les contrôles fondés sur les risques évoluent à l’échelle de l’usage. Les éléments probants devraient inclure les résultats d’audits, les délais de confinement, les violations d’autorisations et les interventions humaines réussies.

Le troisième signal est l’adoption en production liée aux résultats des workflows. La précision en phase pilote et l’enthousiasme des employés ne peuvent pas se substituer à une utilisation durable dans les opérations quotidiennes.

Les DSI devraient surveiller l’usage actif, les taux d’achèvement, la fréquence des exceptions, le temps de revue et le pourcentage de travail généré qui aboutit à un résultat utile.

Ils devraient également mesurer ce qui se passe lorsque le soutien après déploiement diminue. Un système qui dépend d’une intervention constante de ses créateurs n’a pas atteint une production reproductible.

Les unités opérationnelles doivent indiquer si l’IA raccourcit les cycles, accroît les capacités, réduit les erreurs ou améliore les résultats pour les clients. Les équipes financières devraient vérifier les économies annoncées.

Ce signal renforcerait le récit de Google News si l’usage progressait alors que la valeur mesurable resterait faible. Il montrerait que l’adoption seule ne peut pas résoudre le problème du retour sur investissement.

Il affaiblirait ce récit si des programmes matures démontraient des gains reproductibles sur plusieurs workflows après prise en compte de l’ensemble des coûts de sécurité et d’exploitation.

Ces trois signaux sont liés. De meilleurs modèles de valeur sélectionnent des cas d’usage plus solides, des contrôles plus robustes permettent une autonomie sûre, et l’adoption durable des workflows produit des preuves mesurables.

Supprimer un élément crée un résultat fragile. Un système rentable sans contrôles comporte une exposition cachée. Un système sûr sans utilisateurs ne crée aucune valeur.

Un système populaire sans mesures de référence génère une activité impressionnante, mais des retours incertains.

Les DSI devraient résister à la pression de répondre au débat par un nouveau pourcentage global. Leurs propres portefeuilles fournissent des preuves plus utiles qu’un titre agrégé.

Ils peuvent commencer par sélectionner un petit nombre de workflows importants et documenter leur performance actuelle. Chaque projet devrait se voir attribuer un responsable métier, un responsable technique, une classification des risques et un calendrier de revue.

Les équipes devraient calculer les coûts au-delà du développement initial. Ces coûts incluent l’utilisation des modèles, la maintenance des intégrations, la surveillance, les évaluations, la sécurité, le support et la revue humaine.

Elles devraient définir les résultats inacceptables avant d’accorder l’autonomie. Ces limites peuvent couvrir l’exposition des données, les plafonds financiers, l’impact client et les actions d’outils interdites.

Enfin, elles devraient publier les résultats internes, y compris les annulations. Un reporting transparent complique la survie des projets faibles fondée sur le seul enthousiasme.

L’affirmation contestée de 45 % est donc utile comme avertissement, et non comme tableau de bord universel. Elle révèle à quel point une mesure imprécise peut facilement devenir un titre assuré sur l’IA.

La meilleure réponse n’est pas de débattre d’un pourcentage de Google News. Elle consiste à exiger la preuve que chaque système d’IA crée de la valeur une fois pris en compte l’ensemble de ses coûts et de ses risques.

Quels projets passeraient ce test au sein de votre organisation, et lesquels restent financés parce que personne n’a défini ce que signifie la réussite ?