À l’ère de l’IA et de l’automatisation, la mise à disposition des applications n’est plus un simple atout. Elle est absolument essentielle, car les équilibreurs de charge, les passerelles d’API et les maillages de services deviennent la dernière ligne de défense lorsque les systèmes autonomes s’écartent du scénario prévu.
En début de semaine, j’ai perdu un contrôleur.
Plus précisément, j’ai perdu le contrôleur Apex de mon système secondaire. C’est le cerveau de l’automatisation qui gère une partie de l’infrastructure de mon aquarium récifal, notamment deux pompes qui acheminent de l’eau de mer fraîche vers le système principal lors des changements d’eau.
Ces pompes étaient configurées avec une valeur de secours définie sur ON, une mesure de sécurité par défaut en cas d’absence de communication avec le système. Ainsi, lorsque le contrôleur est tombé en panne, elles se sont mises en marche et ont continué à fonctionner. Sans contrôle. Sans coordination. Sans surveillance.
Le résultat ? La cuve principale a failli déborder, tandis que Lori, prise de panique, tentait de contenir la situation. Un rappel que l’automatisation sans garde-fous n’a rien d’intelligent. Elle est risquée.
Et ce rappel est directement lié à la manière dont nous concevons les architectures informatiques modernes, en particulier à l’heure où l’IA commence à prendre les commandes.
La sécurité de l’automatisation dépend de son mode de défaillance
Ce qui s’est passé dans le réservoir n’était dû ni à un bug ni à un problème matériel. Les pompes ont fait exactement ce qu’on leur avait demandé. Le problème, c’est que lorsque le contrôleur est tombé en panne, elles ont continué à fonctionner. Il n’y avait aucun coupe-circuit, aucun dispositif de surveillance externe, aucune stratégie intelligente de repli.
C’est exactement ce qui peut se produire dans un système informatique piloté par l’IA.
Imaginez que des mises à jour de politiques générées par l’IA soient appliquées à une infrastructure en production. Ou que des décisions d’orientation du trafic en temps réel reposent sur un modèle qui se dégrade silencieusement. Ou encore qu’un pipeline de déploiement continue d’appliquer des changements parce que le contrôleur n’a jamais explicitement dit « stop ».
Dans ces moments-là, le silence ne vaut pas approbation. Il est synonyme de danger.
Le rôle des répartiteurs de charge en tant que disjoncteurs
Dans la plupart des architectures d’entreprise, nous nous appuyons sur les répartiteurs de charge, les passerelles d’API et les maillages de services pour jouer le rôle de disjoncteurs. Ils surveillent l’état de santé des systèmes, détectent les problèmes de latence, appliquent une logique de nouvelle tentative et isolent les systèmes défaillants avant qu’ils n’entraînent la panne de tous les autres.
Il ne s’agit pas seulement de bonnes pratiques opérationnelles : c’est ainsi que nous circonscrivons les défaillances et préservons la confiance dans les systèmes autonomes.
Lorsque le plan de contrôle devient indisponible, le rôle de l’équilibreur de charge est d’interrompre le trafic, et non de supposer que tout va bien.
Parfois, « fail ON » est la bonne solution
Bien sûr, tous les systèmes ne doivent pas s’arrêter en cas de panne. Dans mon aquarium récifal, les pompes de brassage du bac principal sont également automatisées, mais elles sont délibérément configurées pour rester en marche en cas de défaillance.
Car sans circulation, le taux d’oxygène baisse et les poissons meurent.
C’est là toute la nuance. Certains systèmes doivent continuer à fonctionner quoi qu’il arrive, comme le DNS, la gestion des identités et la télémétrie de base. Mais qu’en est-il de l’automatisation des processus, comme la génération de politiques ou les déploiements progressifs ? Ces systèmes doivent s’arrêter par défaut si le contrôleur disparaît.
Et c’est là que les agents d’IA créent une véritable tension : ils ne savent pas toujours quand ils se trompent. C’est pourquoi l’architecture qui les entoure, elle, doit le savoir.
L’adoption de l’IA progresse, tout comme la nécessité de fixer des limites
Les résultats du rapport F5 2025 sur l’état des stratégies applicatives confirment ce que la plupart d’entre nous constatent déjà sur le terrain : l’IA passe de la suggestion à l’action.
- 77 % des personnes interrogées ont déclaré vouloir que l’IA génère des suggestions pour ajuster les politiques et les configurations.
- 45 % souhaitent que l’IA ajuste automatiquement ces politiques en temps réel afin de respecter les SLO.
- 55 % souhaitent que l’IA exécute des scripts pour déployer de nouvelles configurations et politiques ou ajuster celles qui existent déjà.
Cela nous apprend quelque chose d’important : nous entrons dans l’ère des agents numériques autonomes, et les organisations ne font pas marche arrière. Elles accélèrent.
Mais une IA capable d’écrire ou de modifier des configurations sans validation humaine ? C’est comme laisser les pompes tourner sans aucune surveillance. Ce n’est qu’une question de temps avant que quelque chose ne soit inondé ou ne tombe en panne.
Conclusion : concevez des systèmes qui savent quand s’arrêter
L’IA n’est pas facultative. Les coupe-circuits non plus.
À mesure que nous intégrons davantage d’agents intelligents à nos systèmes — dans la gestion des flux de trafic, les moteurs de configuration et les décisions stratégiques — nous devons doter l’infrastructure sous-jacente de limites claires et automatiques.
Équilibreurs de charge. Passerelles. Contrôles d’intégrité. Logique de nouvelle tentative. Il ne s’agit pas seulement de modèles, mais de garde-fous pour une autonomie sûre. C’est l’une des principales raisons qui ont motivé l’élaboration du Top 10 de la distribution d’applications, afin de mettre en lumière l’importance de la distribution d’applications pour l’exploitation et la sécurisation d’un environnement numérique. Car elle ne fera que gagner en importance à mesure que l’automatisation remplacera les opérations manuelles dans le rôle de pilotage des activités numériques.
L’automatisation sans discipline n’est pas synonyme de résilience.
Ce n’est que du chaos orchestré par une tâche cron.
À propos de l’auteur
Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.
Autres articles de Lori Mac VittieArticles de blog associés
F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.