Quand la complexité devient l’ennemie : comment la prolifération des workflows opérationnels menace les performances et la livraison

Dans un monde où la livraison d’applications ne cesse d’évoluer, les organisations investissent massivement dans des infrastructures et des applications modernes, ainsi que dans l’automatisation intelligente. Pourtant, malgré ces investissements, nombre d’entre elles restent confrontées à des problèmes qui devraient être résolus depuis longtemps : des systèmes qui cèdent sous la pression, des politiques de déploiement qui ne s’appliquent pas de manière cohérente dans tous les environnements et des workflows qui se retrouvent paralysés au moment même où la rapidité est la plus cruciale.

Deux des dix principaux défis auxquels les organisations sont aujourd’hui confrontées en matière de livraison sont particulièrement révélateurs : le manque de tolérance aux pannes et de résilience, ainsi que l’incompatibilité des politiques de livraison. À première vue, ces difficultés peuvent sembler liées à l’infrastructure ou aux outils, mais en y regardant de plus près, il apparaît clairement qu’elles sont les symptômes d’un défaut structurel plus profond : la complexité des workflows opérationnels.

Cette complexité n’est pas qu’un simple désagrément. Elle dégrade activement les performances d’exécution, compromet la cohérence des politiques et empêche les organisations d’exploiter pleinement le potentiel de leurs investissements dans la transformation numérique.

La complexité est le principal obstacle opérationnel

Dans notre dernière étude, 54,8 % des personnes interrogées ont indiqué que leur principal défi lors de la conception de workflows opérationnels pour la livraison et la sécurité des applications était le « trop grand nombre de tâches dans le processus ». Cela signifie que plus de la moitié des décideurs et des responsables de la mise en œuvre informatique reconnaissent directement que leurs systèmes sont trop complexes pour fonctionner efficacement.

Et ce n’est pas le seul indicateur. Presque autant de personnes interrogées, soit 53,6 %, ont déclaré que leurs workflows impliquaient « trop d’API différentes ». Par ailleurs, 45,3 % ont cité la nécessité de maîtriser « trop de langages différents » comme l’un des principaux défis. Cette fragmentation se situe au niveau opérationnel : différents outils, différentes syntaxes, différents responsables. Tout cela alourdit la charge de travail et accroît les risques.

Ces chiffres devraient inquiéter tous ceux qui se soucient de la disponibilité, de l’expérience utilisateur ou de l’efficacité opérationnelle.

Comment la complexité compromet la résilience

Commençons par « ADC02 Manque de tolérance aux pannes et de résilience ». Dans une pile applicative moderne classique, il peut y avoir une demi-douzaine de couches différentes chargées du routage, de l’équilibrage de charge, de la découverte de services, de l’authentification, de la télémétrie et de l’application des politiques. Chacune de ces couches peut être gérée par une équipe différente. Chacune peut avoir sa propre API, son propre processus de contrôle des modifications et son propre langage.

Que se passe-t-il lorsque quelque chose ne va pas ?

Un basculement ne se déclenche pas, car la dépendance en amont n’a pas détecté la défaillance du nœud. Un nouveau déploiement achemine mal le trafic, car le maillage de services n’était pas synchronisé avec l’équilibreur de charge. Il faut plusieurs minutes pour isoler un pic de latence, car les outils d’observabilité n’étaient pas configurés de manière cohérente sur les différentes couches.

Il ne s’agit pas de rares cas limites. Ce sont des défaillances opérationnelles quotidiennes dues à la prolifération des workflows. Elles sont directement liées aux données qui révèlent que 29 % des personnes interrogées s’appuient encore sur des scripts personnalisés pour prendre en charge l’automatisation. C’est un signal d’alarme majeur. Contourner la complexité à l’aide de scripts, ce n’est pas de l’automatisation : c’est un assemblage fragile. Il se brise lorsque l’environnement évolue et retarde le rétablissement lorsque les performances se dégradent.

Lorsque les workflows opérationnels sont alourdis par de multiples transferts, des connaissances informelles et des interventions correctives manuelles, il n’existe aucune véritable tolérance aux pannes. Il ne reste que l’espoir.

Lorsque les politiques ne suivent pas l’application

Lorsque la plupart des gens entendent parler de « dérive des politiques », ils pensent à la sécurité. Mais la dérive des politiques de mise à disposition des applications — comme les règles de routage du trafic, le comportement de l’équilibrage de charge ou les configurations de limitation du débit — peut être tout aussi préjudiciable. C’est l’une des causes de ADC07 Politiques de mise à disposition incompatibles.

Dans un pipeline bien orchestré, les politiques doivent accompagner l’application depuis l’environnement de développement jusqu’à la production, en passant par la préproduction. Mais dans la pratique, les transitions entre les environnements sont souvent manuelles, incohérentes et dépendantes des outils utilisés. Une règle d’équilibrage de charge définie en préproduction peut ne pas correspondre à celle configurée dans le cloud public. Une politique de routage testée en développement peut être omise en production en raison de contraintes propres à l’environnement ou d’un oubli. Seuils de déploiement canari, comportements de mise en cache, logique de basculement : toutes ces politiques de la couche de livraison sont fréquemment sujettes à des dérives lors du déploiement.

La cause profonde est la même que celle mise en évidence dans le rapport F5 2025 sur l’état de la stratégie applicative : la complexité. Avec 45,3 % des personnes interrogées qui évoquent « un trop grand nombre de langages différents nécessaires » et 53,6 % « un trop grand nombre d’API différentes », il est clair que les workflows de livraison sont fragmentés entre différents écosystèmes d’outils. Chaque environnement peut utiliser des modèles de configuration ou des plateformes d’infrastructure en tant que code différents, ce qui nécessite une transposition à chaque étape.

La transposition introduit des risques. Elle entraîne également des retards. Lorsque les politiques de déploiement doivent être réécrites manuellement ou adaptées d’un système à l’autre, la cohérence des déploiements en pâtit. Et dans les systèmes distribués, l’incohérence est souvent pire que l’échec, car elle engendre des comportements imprévisibles.

Imaginez un déploiement multirégional dans lequel une politique d’orientation du trafic ne s’applique que dans une seule zone. Ou encore une application mondiale dont les règles de mise en cache varient d’un nœud périphérique à l’autre. Il en résulte une expérience utilisateur dégradée, difficile à diagnostiquer et encore plus difficile à corriger.

Pour avancer rapidement sans rien casser, les organisations ont besoin de politiques de déploiement déclaratives, portables et appliquées de manière cohérente à chaque niveau de la pile technologique. C’est impossible lorsque les workflows reposent sur un assemblage disparate de processus manuels et de logiques propres à chaque équipe.

Tant que les politiques de livraison ne seront pas considérées comme des éléments de premier ordre — c’est-à-dire placées sur un pied d’égalité avec le code applicatif et la configuration de l’infrastructure — les organisations continueront à subir des dérives, des interruptions de service et des retards de livraison. La simplification de ces workflows constitue la première étape, et la plus indispensable.

La rationalisation n’est désormais plus une option

Réduire la complexité des workflows ne consiste pas à simplifier le schéma d’architecture ni à faciliter la vie des équipes d’exploitation (même si cela permettrait d’atteindre ces deux objectifs). Il s’agit de tenir les promesses fondamentales des infrastructures applicatives modernes : rapidité, résilience et cohérence.

Les organisations qui souhaitent améliorer les performances d’exécution et garantir un processus de livraison prévisible doivent examiner attentivement le nombre d’outils, d’équipes et de transferts impliqués dans leurs pipelines. Plus important encore, elles doivent se demander combien de ces étapes apportent une réelle valeur ajoutée et combien ne servent qu’à contourner les limites du système.

La solution n’est pas toujours un nouvel outil. Parfois, il faut moins d’outils. Parfois, il s’agit d’une plateforme unique et unifiée qui applique la logique de livraison avec la même syntaxe et le même comportement dans tous les environnements. Parfois, il s’agit d’automatiser non seulement le déploiement, mais aussi la gouvernance, afin que les politiques de livraison s’appliquent sous forme de code, et non de liste de contrôle.

La voie vers une livraison résiliente et fiable passe par la simplification. Tant que nous ne considérerons pas la complexité comme un risque majeur, elle continuera de fragiliser tout ce que nous avons bâti sur cette base.