Trop d’alertes peuvent masquer les premiers signes d’une panne

La modernisation du cloud laisse la résilience à la charge de l’entreprise

Une entreprise peut moderniser son infrastructure, automatiser ses opérations et adopter des services cloud natifs, conçus pour fonctionner dans des environnements cloud, tout en laissant ses applications vulnérables aux défaillances. Gartner identifie cinq évolutions à l’origine de cette tension : les investissements dans la rapidité et l’évolutivité peuvent coexister avec une fragilité croissante. Cela remet en question la promesse de disponibilité « toujours active » en demandant si les organisations peuvent encore comprendre et gérer les défaillances à travers les services dont dépendent leurs applications.

Gartner avance cet argument dans son invitation à la Gartner IT Infrastructure, Operations & Cloud Strategies Conference 2026. L’entreprise a un intérêt commercial, car elle vend l’accès à l’événement et en tire profit lorsque les dirigeants sollicitent ses conseils sur la résilience. Gartner présente la conférence comme un lieu pour comprendre les nouveaux schémas de défaillance, tirer des enseignements des analyses actuelles, comparer les stratégies de résilience et se préparer à de nouvelles perturbations. Gartner soutient que la distribution croissante et l’interdépendance rendront ces décisions plus importantes.

Pour les responsables technologiques, la question pratique derrière cette invitation est de savoir si l’abstraction a été confondue avec un transfert de responsabilité. L’abstraction permet aux équipes d’utiliser un service sans gérer toute la mécanique sous-jacente, mais l’organisation reste responsable du comportement de ses applications lorsque ce service tombe en panne. À mesure que les plateformes prennent en charge davantage de travail, les dirigeants doivent donc comprendre quelles responsabilités leurs équipes doivent conserver.

La défaillance d’une application peut commencer au-dessus d’une infrastructure stable

Conserver cette responsabilité commence par distinguer la disponibilité des applications de l’état de santé de l’infrastructure. Le matériel et les centres de données peuvent rester stables alors qu’une application devient indisponible parce qu’un service dont elle a besoin a échoué. Il s’agit d’une défaillance de chaîne de services : une défaillance parmi des services connectés empêche l’application de fonctionner. Une infrastructure saine ne suffit donc pas, à elle seule, à établir qu’une application dispose de tout ce dont elle a besoin pour fonctionner.

Gartner soutient que les pannes modernes commencent rarement dans l’infrastructure physique et surviennent plutôt parmi des services connectés. L’entreprise identifie plusieurs points de défaillance possibles : les systèmes d’identité, les fabrics réseau qui relient les composants de l’infrastructure, les bases de données managées et les API tierces, les interfaces par lesquelles les applications utilisent des services externes. Dans « From Automation to Reasoning: How AI Redefines Infrastructure », Gartner relie cette préoccupation à la complexité des chaînes de services et à l’automatisation qui opère au-dessus de l’infrastructure. Évaluer les composants séparément laisse une question sans réponse : comment l’application se comportera-t-elle si l’un d’eux devient indisponible ?

La connexion de services entre différents environnements prolonge cette question. Dans « Accelerating Operational Innovation From Cloud to AI », Gartner souligne que les architectures hybrides, qui relient des environnements sur site et cloud, et les architectures multicloud, qui utilisent plusieurs clouds, introduisent des points d’intégration susceptibles de devenir des points de défaillance. Chaque connexion ajoute une relation que l’organisation doit comprendre. La résilience des applications dépend donc de la manière dont l’ensemble des services fonctionne ensemble.

Pourtant, l’équipe responsable d’une application peut n’avoir de visibilité que sur une partie de ces relations. L’abstraction du cloud masque la complexité sous-jacente, tandis que les frontières organisationnelles peuvent séparer la propriété de l’application de la connaissance des services de support. Une équipe peut donc être responsable de la disponibilité d’une application alors que la cause d’une défaillance se situe en dehors de l’environnement qu’elle peut voir. Une visibilité incomplète ne change rien à cette responsabilité.

PARLONS-EN !

Un projet en tête ?
Planifiez un appel de 30 minutes avec nous.

Des experts senior pour vous aider à avancer plus vite : produit, tech, cloud & IA.

Planifier un appel

Veuillez saisir une adresse email professionnelle valide.

Les données opérationnelles doivent rendre les dépendances compréhensibles

Une visibilité incomplète peut persister même lorsque les systèmes produisent de grandes quantités de données. Dans « The Distraction Tax: How Operational Noise Is Quietly Killing Innovation », Gartner décrit comment le volume d’alertes et la télémétrie dupliquée, c’est-à-dire les données que les systèmes produisent sur leur état et leur comportement, submergent les équipes opérationnelles. Davantage de données peut rendre les changements importants plus difficiles à repérer lorsque les signaux utiles sont en concurrence avec des notifications répétées ou routinières.

Gartner relie ce bruit opérationnel à une baisse de l’attention, ce qui rend les premiers signes d’une défaillance plus large plus difficiles à distinguer. Les dépendances cachées aggravent le problème, car une équipe peut voir un avertissement sans comprendre quelle application il menace. Des avertissements excessifs rendent ensuite cette relation plus difficile à examiner. Un maillon faible peut rester non identifié même si des données à son sujet existent quelque part dans l’environnement.

Comprendre ces relations exige une visibilité au-delà des propres systèmes de l’entreprise. Dans « Leadership Vision 2026: Infrastructure and Operations Through 2028 », les analystes de Gartner mettent l’accent sur la gouvernance et la visibilité à travers les domaines opérationnels, y compris les « services de tiers et de quatrièmes parties ». Les services de quatrième partie approvisionnent les propres fournisseurs d’une organisation, de sorte que l’exposition peut aller au-delà des relations directes avec les fournisseurs. La gouvernance doit s’étendre suffisamment le long de ces dépendances pour que les dirigeants comprennent les risques dont héritent leurs applications.

L’automatisation exige de conserver une expertise humaine

Une vision plus claire des dépendances laisse encore une question pratique : les personnes peuvent-elles agir lorsqu’une défaillance dépasse ce que l’automatisation peut gérer ? Gartner oppose les opérations cloud actuelles à l’ère des centres de données, lorsque la menace persistante de panne matérielle imposait une pratique régulière de reprise après sinistre. Des exercices répétés construisaient une discipline opérationnelle et une connaissance pratique de la manière de restaurer les systèmes. Les équipes pouvaient s’appuyer sur cette expérience lorsque quelque chose tournait mal.

L’abstraction du cloud change la fréquence à laquelle les équipes pratiquent la reprise, car les plateformes prennent en charge une plus grande part des opérations sous-jacentes. Gartner soutient qu’un contact réduit avec les processus de défaillance et de reprise peut affaiblir l’expérience pratique. Une organisation peut donc supposer que ses équipes conservent une capacité de réponse qu’elles ont moins d’occasions d’exercer. Le risque augmente lorsque les modes opératoires changent sans décision correspondante sur les compétences à maintenir.

L’automatisation pilotée par l’IA rend cette décision plus importante. Dans « Autonomous IT: A New Paradigm for Secure Endpoint Management with AI in Real Time », Gartner décrit des systèmes qui observent les conditions, raisonnent à leur sujet et agissent sans intervention humaine. À mesure que ces systèmes prennent en charge un travail qui exigeait auparavant une attention directe, les dirigeants doivent se demander qui peut comprendre et gérer une défaillance inattendue. Déléguer l’exécution change la manière dont le travail est effectué tout en laissant l’entreprise responsable des conséquences.

Gartner aborde cette capacité dans « I&O Skills: What’s Needed Now, What’s Needed in the Future », qui insiste sur la reconstruction des compétences en infrastructure et opérations plutôt que de supposer que les plateformes cloud absorberont toute la complexité. Ces compétences incluent la capacité pratique à réagir lorsque les systèmes se comportent de manière inattendue. L’automatisation peut améliorer l’efficacité tout en réduisant les occasions d’acquérir cette expérience, de sorte que les dirigeants doivent décider délibérément comment conserver l’expertise. Un investissement continu dans les compétences aide les équipes à utiliser des systèmes autonomes tout en préservant le jugement nécessaire pour en reconnaître les limites.

L’architecture et la gouvernance doivent se préparer à la défaillance

L’expertise conservée a besoin d’une architecture qui offre aux personnes des options utiles lorsqu’une défaillance survient. Les systèmes distribués, c’est-à-dire les applications dont le travail s’étend sur des services connectés, rencontreront des défaillances ; les choix architecturaux doivent donc en tenir compte. Gartner appelle à examiner les faiblesses dans la manière dont les services s’articulent et à investir dans des frameworks qui guident des décisions cohérentes en matière de résilience. Se préparer signifie affronter des constats architecturaux difficiles et accepter qu’ils modifient la conception.

La visibilité sur les dépendances donne une base à ces décisions, tandis que la gouvernance intègre les risques qui en résultent dans la responsabilité opérationnelle. Dans « Accelerating Operational Innovation From Cloud to AI », Gartner relie ce travail à une gouvernance proactive et à des opérations prédictives, c’est-à-dire des opérations qui anticipent les problèmes émergents. La prédiction aide lorsque les personnes et les systèmes automatisés comprennent quelles dépendances sont affectées par un avertissement et peuvent agir avant que le problème ne se propage. Sa valeur dépend du lien entre l’information et une décision sur le comportement de l’application.

Les dirigeants peuvent vérifier si ce lien existe en posant la question : « Savons-nous quelle est l’intégralité de notre chaîne de dépendances ? » La réponse doit inclure les services au-delà des frontières organisationnelles, les fournisseurs directs et les fournisseurs de ces fournisseurs. Elle doit aussi distinguer les données collectées d’une explication compréhensible de quels services dépendent de quels autres. Identifier les relations qui restent floues met au jour des lacunes qui, autrement, peuvent dissimuler des maillons faibles.

Une fois ces relations comprises, la question architecturale devient : « Nos systèmes peuvent-ils se dégrader de manière maîtrisée lorsqu’un service tombe en panne ? » Une dégradation maîtrisée signifie continuer à fournir un service utile lorsqu’une dépendance devient indisponible, même si certaines fonctionnalités sont perdues. L’évaluer exige d’examiner le comportement de l’application en situation de défaillance, en particulier là où l’intégration crée davantage de façons pour un problème de se propager. L’état de santé des composants ne peut pas répondre à cette question au niveau de l’application.

Même une architecture conçue pour tolérer les défaillances a besoin de personnes prêtes à intervenir, ce qui rend la dernière question très concrète : « À quand remonte la dernière fois que nous avons mené un exercice manuel de résilience ? » L’exercice teste ce que les personnes au sein de l’organisation peuvent faire directement lorsque les opérations automatisées sont insuffisantes. Là où l’automatisation a réduit l’expérience pratique, un exercice vérifie si la capacité de réponse que les dirigeants supposent toujours disponible l’est réellement. Ses conclusions peuvent révéler des compétences et un niveau de préparation qui nécessitent un nouvel investissement.

Principaux enseignements pour les dirigeants

• Conserver la responsabilité de la résilience : Les plateformes cloud prennent en charge le travail opérationnel tandis que l’entreprise reste responsable de la disponibilité des applications. Les responsables technologiques doivent prendre des décisions explicites sur les responsabilités et les capacités de reprise qui restent en interne.
• Cartographier les dépendances de services : Les responsables d’applications ont besoin de visibilité sur les systèmes d’identité, le réseau, les bases de données et les API externes à travers les environnements cloud. Étendez cette vue aux fournisseurs de vos fournisseurs afin de mettre au jour les risques au-delà des contrats directs.
• Rendre les données opérationnelles utiles : Les équipes opérationnelles ont besoin d’alertes qui relient les problèmes de service aux applications qu’ils menacent. Réduire la télémétrie dupliquée et clarifier les dépendances aide les équipes à reconnaître les premiers signes d’une défaillance plus large.
• Préserver l’expertise de reprise : Les responsables infrastructure et opérations doivent maintenir des compétences pratiques de reprise à mesure que l’automatisation absorbe le travail routinier. Des exercices manuels de résilience vérifient si les personnes peuvent intervenir lorsque les réponses automatisées sont insuffisantes.
• Concevoir en tenant compte des défaillances de service : Les architectes doivent évaluer si les applications conservent une fonctionnalité utile lorsque les services de support tombent en panne. Utilisez les cartes de dépendances et les enseignements des exercices pour prioriser les changements de conception, les lacunes de gouvernance et l’investissement dans les compétences.