Une enquête de Google Cloud sur l’IA révèle que les logiciels existants freinent la modernisation

Google Cloud a publié le 9 novembre des résultats montrant que 49 % des décideurs interrogés associaient les logiciels sur site à des initiatives technologiques retardées ou réduites. Ces initiatives incluaient l’IA, bien que ce résultat n’isole pas les projets d’IA. L’enquête de Google Cloud sur l’IA chiffre concrètement un conflit bien connu dans les entreprises : maintenir les opérations existantes entre en concurrence avec le développement de nouvelles capacités.

L’étude, menée avec Hypothesis Group, a interrogé 1 250 décideurs IT et métiers d’entreprises aux États-Unis. Google s’appuie sur ces résultats pour plaider en faveur d’un plus grand choix architectural et d’une moindre dépendance envers les fournisseurs établis. Sa préoccupation centrale est compréhensible : les agents d’IA, des logiciels capables de poursuivre des tâches par des actions successives, héritent des limites des systèmes auxquels ils accèdent.

Microsoft offre un point de comparaison utile. Ses recherches mettent l’accent sur la préparation organisationnelle parallèlement à l’adoption par les employés, plutôt que de considérer le remplacement des infrastructures comme la réponse centrale. La tension présente dans les deux analyses réside entre l’élargissement de l’accès à l’IA et la préparation des processus métier à son utilisation. Pour les responsables technologiques, cela oriente le débat vers l’intégration, la responsabilité opérationnelle et la question de savoir si les nouvelles dépenses libèrent réellement de rares capacités d’ingénierie.

Ce que l’enquête de Google Cloud sur l’IA a réellement mesuré

L’enquête mesure les contraintes déclarées par les décideurs, plutôt que de démontrer qu’une stratégie de modernisation particulière les élimine.

Jeanette Manfra, responsable des risques et de la conformité chez Google Cloud, a présenté les résultats dans une annonce consacrée à une enquête sur les logiciels hérités. Le rapport associé est daté d’octobre 2026, tandis que sa méthodologie situe le travail de terrain en août. La publication offre donc un compte rendu récent d’expériences recueillies auparavant, plutôt qu’une mesure en temps réel des déploiements de novembre.

Une définition importante façonne l’interprétation. L’étude classe les logiciels d’entreprise hébergés localement ou sur site comme hérités, en les opposant aux logiciels hébergés et gérés dans le cloud. Cette définition concerne les modalités de déploiement et de gestion. Les lecteurs doivent éviter de supposer que tous les systèmes concernés sont obsolètes, non pris en charge ou techniquement inadaptés à l’IA.

Cette distinction est importante, car l’emplacement et l’état répondent à des questions différentes. Une application exploitée localement peut disposer d’interfaces claires et d’une maintenance rigoureuse. Une application cloud peut encore contenir des enregistrements confus, des autorisations incohérentes ou des règles métier étroitement couplées. Aucune de ces observations ne contredit l’expérience des répondants, mais toutes deux limitent les conclusions que les acheteurs devraient en tirer.

Les 49 % rapportés regroupent également plusieurs résultats : retards, réduction de périmètre, mises en pause et annulations. Ils représentent différents degrés de perturbation. Un ajustement temporaire du calendrier n’a pas les mêmes conséquences métier que l’abandon d’un projet. De même, l’inclusion d’autres initiatives technologiques signifie que ce résultat ne peut pas être interprété comme un taux d’annulation de projets d’IA.

Cette réserve laisse intact un constat significatif. Les répondants associent leurs modalités logicielles existantes à des obstacles aux changements prévus. Pour les acheteurs d’entreprise, cela indique que l’environnement environnant mérite de l’attention au même titre que le produit d’IA évalué.

Cependant, une réponse à une enquête ne peut pas établir toute la chaîne des responsabilités. Une initiative à l’arrêt peut impliquer des limites applicatives, des restrictions d’achat, une expertise insuffisante, des priorités concurrentes ou une justification métier peu claire. Plusieurs causes peuvent coexister dans un même projet.

L’enquête de Google Cloud sur l’IA est donc surtout utile comme diagnostic des frictions organisationnelles perçues. Elle donne aux dirigeants une raison d’examiner leurs propres dépendances. Elle ne leur indique pas quelle application remplacer, quel fournisseur choisir, ni si une migration doit précéder un déploiement précis.

Cette différence sépare un signal de recherche utile d’une conclusion d’achat trop générale. La question suivante est de savoir qui doit résoudre ces frictions et quel travail ces personnes effectueraient autrement.

La pression de maintenance pèse sur les équipes censées fournir l’IA

La pression immédiate s’exerce sur les équipes responsables à la fois de la continuité opérationnelle et de la livraison de nouvelles solutions d’IA.

Une organisation d’ingénierie ne peut pas considérer sa charge de travail existante comme facultative simplement parce que les dirigeants imposent une échéance liée à l’IA. Les correctifs de sécurité, les modifications d’accès, la réponse aux incidents et le support applicatif restent nécessaires. L’attribution d’un objectif supplémentaire ne crée pas automatiquement la capacité requise pour l’atteindre.

Cela crée un problème budgétaire que les seuls chiffres d’effectifs peuvent masquer. Une équipe peut sembler disposer de ressources suffisantes alors que ses spécialistes restent mobilisés par des systèmes exigeant leurs connaissances spécifiques. La contrainte pertinente est souvent l’expertise disponible pendant la période de livraison, plutôt que le nombre total d’employés.

Prenons l’exemple illustratif d’un agent de service interne qui aide les employés à résoudre des problèmes de compte. Produire une réponse plausible n’est qu’une partie de la mission. Le processus environnant doit identifier l’employé, établir les accès autorisés, récupérer des informations à jour et orienter les exceptions vers une personne responsable.

Si l’agent peut modifier un compte, l’organisation a également besoin de règles d’approbation et d’un enregistrement de l’action. Une démonstration efficace peut éviter une grande partie de ce travail opérationnel. Un service de production ne peut pas dépendre de quelqu’un qui corrige manuellement chaque cas inhabituel par la suite.

Ces exigences expliquent pourquoi les développeurs et les équipes de sécurité subissent des pressions venant de directions différentes. Les responsables métier veulent des progrès visibles. Les équipes opérationnelles doivent préserver la disponibilité. Les réviseurs sécurité ont besoin de preuves suffisantes pour approuver les accès. Sans priorités explicites, le travail d’intégration peut devenir une dépendance sans responsable entre ces groupes.

La maintenance affecte également le séquencement. Le remplacement d’une application peut à terme réduire l’effort de support, tout en nécessitant un travail substantiel avant que ce bénéfice n’apparaisse. Pendant la transition, les équipes peuvent devoir prendre en charge les processus existants tout en apprenant le système de remplacement. Une proposition de modernisation doit donc rendre compte de la charge de travail temporaire.

C’est là que les promesses générales de libérer les ingénieurs méritent d’être examinées. La question pertinente est de savoir quelles tâches récurrentes disparaissent, qui les exécute aujourd’hui et quand ces personnes deviennent disponibles. Transférer la responsabilité à un fournisseur peut aider, mais le travail d’intégration et de supervision conservé a toujours besoin d’un responsable.

Les équipes achats font face à un défi connexe. Elles doivent distinguer la commodité d’acquérir un produit de l’effort nécessaire pour l’exploiter. Un contrat familier peut simplifier l’achat sans résoudre l’accès aux données. Un fournisseur peu connu peut offrir des capacités attrayantes tout en ajoutant un autre ensemble de responsabilités opérationnelles.

Pour les travailleurs du savoir, les conséquences se manifestent par une disponibilité inégale. Un assistant peut résumer des documents avec succès tout en restant incapable d’utiliser les enregistrements nécessaires à une décision importante. L’interface d’IA visible progresse alors plus vite que le flux de travail qui la sous-tend.

La pression est donc autant organisationnelle que technique. La direction doit décider quelles dépendances méritent un investissement et quels projets proposés doivent attendre. Sinon, chaque nouveau pilote se dispute les mêmes personnes sans modifier les conditions qui ont ralenti ses prédécesseurs.

Ajouter un agent ne supprime pas le travail sous-jacent

L’automatisation renforce l’importance d’interfaces métier fiables, car les actions exigent des limites plus claires que les suggestions.

L’argument de Google devient plus convaincant lorsqu’il est appliqué à un flux de travail précis plutôt qu’au seul emplacement des logiciels. Un système qui produit des conseils peut laisser l’exécution à une personne. Un système autorisé à agir doit rencontrer des règles que l’organisation a rendues explicites.

Prenons une demande d’achat illustrative. Un employé peut demander à un agent de préparer une commande auprès d’un fournisseur approuvé. La tâche linguistique est simple à décrire. La tâche métier comprend la vérification de l’autorisation, la sélection du bon compte, l’application de la politique d’achat et le traitement des articles indisponibles.

Chaque étape introduit une question qu’un texte fluide ne peut pas trancher indépendamment. Quel enregistrement fait autorité ? Le demandeur en a-t-il l’autorisation ? L’achat proposé respecte-t-il la politique ? Que se passe-t-il si la commande aboutit mais que la confirmation échoue ?

Ces questions mettent en évidence la différence entre générer une réponse et finaliser une transaction. L’organisation doit savoir ce qui s’est produit dans ses systèmes, y compris en cas d’exécution partielle. Une réponse conversationnelle assurée ne peut pas se substituer à ces preuves.

Les applications existantes encodent parfois des règles que les employés comprennent par l’expérience plutôt que par la documentation. Un déploiement d’agent peut révéler ces connaissances implicites. Ce qui semble être un problème d’intégration peut en réalité impliquer des décisions non résolues concernant la politique, les exceptions ou les responsabilités.

Le remplacement de l’application ne résoudra pas nécessairement ces décisions. Il peut offrir un meilleur endroit pour les exprimer, mais quelqu’un doit toujours déterminer le comportement attendu. C’est pourquoi les propositions de modernisation devraient identifier la limite métier qu’elles améliorent, plutôt que de s’appuyer sur l’ancienneté du logiciel sous-jacent.

Le compte rendu par Google de son propre déploiement de service client fournit un exemple concret. En avril 2025, l’entreprise a décrit FreshAI de Wendy’s comme gérant les commandes au drive et se développant dans 24 États. Il s’agit d’affirmations de déploiement rapportées par l’entreprise, plutôt que d’une preuve indépendante de la fiabilité générale des agents.

L’exemple illustre néanmoins la valeur d’une tâche définie. Commander de la nourriture implique des entrées reconnaissables, des contraintes de menu et une transaction qui doit parvenir aux opérations du restaurant. Son utilité dépend des connexions au processus de service réel, plutôt que de la seule qualité de la conversation.

Un flux de travail interne d’entreprise nécessite une clarté comparable, même lorsque ses limites sont moins visibles. Une demande visant à examiner un contrat, préparer un renouvellement ou résoudre un problème d’accès exige une destination convenue. Dans le cas contraire, une équipe peut déclarer le succès lorsque l’agent produit du texte, tandis que les employés en aval accomplissent encore le travail de fond.

Cela fait de l’intégration une question de responsabilité. Quelqu’un doit assumer la transition de la recommandation à l’action approuvée, puis de l’action au résultat vérifié. Sans cette responsabilité, l’automatisation peut redistribuer les efforts tout en laissant le processus métier largement inchangé.

Le meilleur argument en faveur de la modernisation identifie ces transitions et démontre qu’elles s’améliorent. Ses preuves devraient montrer moins de transferts non résolus, une exécution fiable et une reprise maîtrisable lorsqu’un problème survient.

Google et Microsoft mettent l’accent sur des voies différentes vers la préparation

Les fournisseurs diffèrent dans leurs priorités, mais les deux analyses font de la préparation organisationnelle un élément central d’un déploiement utile de l’IA.

La position de Google accorde une place importante à la liberté architecturale. La recherche de Microsoft sur la préparation organisationnelle à l’IA met davantage l’accent sur le management, la conception du travail et l’évaluation. Son rapport de mai 2026 s’appuie sur une enquête menée auprès de 20 000 travailleurs utilisant l’IA dans 10 marchés.

Microsoft indique que les conditions organisationnelles sont fortement associées à la valeur que les répondants déclarent retirer de l’IA. Sa méthodologie distingue explicitement l’association statistique de la causalité. Cette prudence importe lorsque l’on compare ces résultats avec le récit de Google : aucune des deux enquêtes n’établit de recette universelle pour un déploiement réussi.

La comparaison reflète également des positions commerciales différentes. Google a intérêt à encourager les acheteurs à reconsidérer des relations d’entreprise établies. Microsoft a intérêt à faire des environnements de travail existants des cadres productifs pour l’IA. Ces incitations expliquent les priorités mises en avant sans invalider automatiquement les résultats de l’une ou l’autre entreprise.

Pour les acheteurs, le choix implique des compromis pratiques. Étendre un environnement établi peut préserver une administration familière et réduire une partie du travail de transition. Introduire une alternative peut accroître les options de négociation ou répondre à une exigence particulière de flux de travail. L’une comme l’autre voie peut décevoir si l’organisation fait l’impasse sur l’évaluation de l’intégration.

L’enquête Google Cloud AI devrait donc inciter à examiner la dépendance plutôt qu’à rejeter automatiquement un fournisseur historique. La dépendance devient déterminante lorsque le remplacement d’un composant entraîne des perturbations inacceptables, fait perdre des informations essentielles ou empêche l’entreprise de fonctionner de manière autonome.

Cette préoccupation s’applique aussi bien à un nouveau fournisseur qu’à un fournisseur existant. Une entreprise peut remplacer une contrainte familière par une autre, moins connue. Un contrat différent ne garantit pas à lui seul une plus grande liberté.

Un choix réel exige des preuves opérationnelles. Un acheteur doit comprendre si les enregistrements restent exploitables hors du produit, si les autorisations peuvent être reconstituées et si le travail accompli reste vérifiable. Ces questions sont plus révélatrices que le nombre de noms de modèles disponibles dans un menu.

Il existe également une différence entre choisir un modèle d’IA et remplacer une plateforme de flux de travail. Le modèle génère ou interprète des informations. La plateforme peut contenir des instructions, des connexions, des enregistrements et un historique d’approbations. Changer le premier peut être relativement circonscrit, tandis que changer la seconde affecte l’ensemble du processus.

Cela rend la discussion sur les achats plus exigeante. Les acheteurs devraient évaluer l’ensemble du dispositif de travail, y compris les obligations conservées et les conditions de sortie. Une démonstration pratique offre peu d’éléments sur ce qui se produit lorsqu’une connexion critique tombe en panne ou qu’une unité opérationnelle modifie son processus.

La gestion des connaissances offre un parallèle plus restreint. Une base de connaissances consultable est utile lorsque les personnes peuvent retrouver des contenus pertinents dans leur contexte. L’automatisation d’entreprise ajoute d’autres exigences, car les informations récupérées peuvent influencer des actions ayant des conséquences organisationnelles.

La comparaison la plus solide entre Google et Microsoft porte donc sur la manière dont chaque environnement proposé soutient le travail réel. La préférence de marque est un faible substitut à l’examen d’un même processus, des mêmes autorisations et des mêmes critères d’acceptation entre des approches concurrentes.

L’enquête laisse ouvertes d’importantes questions de causalité et de sécurité

Les frictions de maintenance déclarées justifient une enquête, mais elles n’établissent pas qu’une migration vers le cloud produit de meilleurs résultats pour chaque charge de travail.

Le rapport sur la préparation des entreprises qui l’accompagne décrit une enquête en ligne de 20 minutes, complétée par des entretiens qualitatifs. Son échantillon de décideurs américains offre une perspective définie. Les lecteurs devraient conserver ce périmètre à l’esprit lorsqu’ils parlent d’entreprises ailleurs ou d’employés qui ne relèvent ni des achats ni de la direction technologique.

Le rapport indique également que 78 % des répondants estiment que la maintenance technologique détourne des ressources de l’IA, tandis que 48 % considèrent leur pile technologique prête pour un déploiement à grande échelle. Il s’agit d’évaluations de capacité et de préparation. Ce ne sont pas des mesures directes des heures d’ingénierie récupérées après une migration.

Les répondants peuvent décrire avec précision leur frustration sans identifier le meilleur remède. Une équipe confrontée à de fortes exigences de support pourrait bénéficier d’un remplacement, d’une meilleure configuration, de compétences supplémentaires ou d’un périmètre d’IA plus restreint. Choisir entre ces réponses exige des preuves issues de l’environnement concerné.

Le parrainage commercial mérite la même attention pour cette raison. Google vend des services alignés sur l’orientation qu’il propose. La réponse appropriée consiste à examiner les définitions et à comparer les alternatives, tout en conservant les conclusions qui restent utiles après examen.

La définition du déploiement utilisée par l’enquête est particulièrement déterminante. Considérer les logiciels gérés localement comme des systèmes hérités place la comparaison avec le cloud au centre dès le départ. Les acheteurs ont encore besoin d’une évaluation distincte de la maintenabilité, de la sécurité, de la qualité de l’intégration et de l’adéquation aux besoins de l’entreprise.

La sécurité introduit une autre limite à un récit simple de migration. Un service géré peut modifier la personne qui s’occupe de la maintenance de l’infrastructure. Il ne supprime pas la nécessité de décider à quelles informations un agent peut accéder ni quelles actions requièrent un examen.

Le cadre de gouvernance des agents de Gartner traite de cette distinction. L’analyste Shiva Varma soutient que des contrôles uniformes peuvent restreindre excessivement les agents simples tout en ne restreignant pas suffisamment les plus autonomes. Le cadre distingue l’observation, le conseil et l’action nécessitant une approbation.

Cette perspective complique l’hypothèse selon laquelle l’augmentation de l’autonomie représente toujours un progrès. Un agent limité à la préparation d’une recommandation peut convenir à un flux de travail aux conséquences importantes. Exiger une approbation est une décision de conception dont la valeur dépend de l’action et de ses effets potentiels.

Un acheteur d’entreprise prudent devrait donc distinguer l’amélioration de l’infrastructure de l’amélioration des autorisations. Un meilleur hébergement peut soutenir la disponibilité et la maintenance. De meilleures autorisations définissent ce que le système est autorisé à faire. Les deux méritent de l’attention, et aucune ne devrait se substituer à l’autre.

L’enquête Google Cloud AI ne résout pas l’équilibre entre ces investissements. Elle identifie des contraintes perçues que les dirigeants peuvent examiner. L’erreur analytique consisterait à transformer ce signal en preuve qu’une architecture, un fournisseur ou un niveau d’autonomie est intrinsèquement préférable.

Un autre problème de mesure apparaît après le déploiement. Les employés peuvent consacrer moins de temps à initier le travail, mais davantage à vérifier des résultats incertains. Une affirmation de productivité doit tenir compte de cet effort de contrôle, ainsi que du support et de la reprise. Sinon, une automatisation apparente peut dissimuler un travail transféré à une autre équipe.

Surveillez les flux de travail achevés, les preuves de changement et la reprise

Les prochaines preuves utiles relieront les décisions de modernisation à des résultats opérationnels que les acheteurs peuvent examiner.

Au cours des prochains mois, le premier signal à surveiller est la communication des clients sur les flux de travail achevés. Les informations utiles distingueront une démonstration d’un usage récurrent et expliqueront ce qui constitue une réalisation réussie. Elles devraient également préciser où une intervention humaine reste nécessaire.

Ces preuves renforceraient l’argument de Google si la modernisation supprimait des contraintes identifiables et produisait des améliorations opérationnelles répétables. Elles affaibliraient une affirmation générale en faveur de la migration si les projets exigeaient encore d’importantes corrections manuelles malgré le remplacement de l’environnement sous-jacent.

L’achèvement seul est insuffisant lorsque le processus produit des erreurs inacceptables. Les acheteurs ont besoin de preuves concernant l’exactitude et l’effort requis pour résoudre les exceptions. Un flux de travail qui se termine rapidement tout en créant des litiges en aval a déplacé le problème au lieu de le résoudre.

Le deuxième signal est le changement démontré. Les annonces de produits concernant les connecteurs ou le choix de modèles méritent un examen plus attentif lorsque les clients montrent qu’un processus opérationnel résiste au changement d’un composant. La préservation des autorisations, des critères d’évaluation et des enregistrements exploitables constituerait une preuve significative de flexibilité.

Un changement qui exige une reconstruction importante raconte une autre histoire. Il suggère qu’un choix nominal coexiste avec une dépendance opérationnelle substantielle. Cette distinction comptera lorsque les acheteurs compareront les plateformes de travail établies avec des environnements d’agents alternatifs.

Le troisième signal est la reprise après une défaillance contrôlée. Les retours de clients et les évaluations techniques devraient expliquer ce qui se produit lorsqu’un accès expire, qu’une application connectée devient indisponible ou qu’une action n’est exécutée que partiellement. Les preuves de reprise révèlent le comportement du système au-delà de la démonstration favorable.

Une responsabilité claire renforcerait la confiance. Une équipe devrait pouvoir identifier le dernier état vérifié, déterminer quelles actions ont eu lieu et décider comment le travail reprend. Si ces réponses exigent à chaque fois une enquête informelle, la charge opérationnelle reste non résolue.

Ces signaux aident également à distinguer les contraintes d’infrastructure des contraintes de processus. Une connexion défaillante peut indiquer une dépendance technique. Un conflit d’approbation non résolu renvoie à la gouvernance. Les deux peuvent bloquer la livraison, mais ils appellent des réponses différentes.

L’enquête Google Cloud AI donne aux dirigeants d’entreprise une raison d’examiner où va la capacité d’ingénierie. Ses résultats sont les plus utiles lorsqu’ils sont traduits en questions sur un service spécifique, ses dépendances et les personnes responsables de le maintenir utile.

Pour les lecteurs qui prévoient un investissement dans l’IA, suivez le travail au-delà de la réponse de l’assistant. Demandez quel résultat commercial doit se produire, quels enregistrements établissent l’achèvement et qui gère les exceptions. Comparez les propositions à ce même résultat, y compris l’effort de migration et la vérification continue. Maintenez des critères d’acceptation cohérents lorsque vous évaluez une plateforme historique ou une alternative. Exigez que les affirmations de maintenance réduite identifient les tâches supprimées et les responsabilités conservées. Recherchez ensuite des preuves clients que ces changements perdurent durant les opérations ordinaires et les défaillances contrôlées. Quelle dépendance empêche actuellement votre équipe d’achever un travail utile, et quelles preuves montreraient que l’investissement proposé la supprime réellement ?