Notre article ADC09 d’origine fait un constat pragmatique : toutes les applications ne s’intègrent pas parfaitement dans des modèles de mise à disposition standardisés. Certaines nécessitent un routage personnalisé, des intégrations spécialisées ou un traitement particulier qui sort du cadre des modèles par défaut d’équilibrage de charge et de sécurité. La conclusion est tout aussi pragmatique. Si vous essayez de faire entrer toutes les applications dans le même moule, vous risquez soit de les rendre inutilisables, soit de créer des contraintes opérationnelles. La solution a toujours été de rendre la couche de mise à disposition programmable, afin de pouvoir l’adapter sans avoir à tout réécrire.
Ce principe reste valable.
Ce qui a changé, c’est que l’IA a considérablement augmenté le nombre d’applications qui se comportent ainsi. Ce qui relevait autrefois de cas particuliers devient rapidement la norme.
Les systèmes d’IA ne sont pas statiques. Ils sont modulaires, guidés par le contexte et de plus en plus autonomes dans la manière dont ils répondent aux demandes. Cela signifie que le « sur mesure » n’est plus l’apanage de quelques applications : il est désormais inhérent à l’architecture elle-même.
Conséquences des exigences propres aux applications d’IA sur mesure
Impact sur la disponibilité
Dans les systèmes traditionnels, les exigences spécifiques compliquaient souvent la disponibilité, car elles introduisaient une logique personnalisée dans le routage et le basculement. Les modèles standard reposent sur un comportement prévisible. Lorsqu’une application s’en écarte, les stratégies de disponibilité doivent être adaptées en conséquence.
L’IA déplace le problème de l’acheminement des requêtes vers l’aboutissement des décisions.
Une requête adressée à un système d’IA n’est pas une simple transaction. Elle peut impliquer la sélection d’un modèle, la récupération du contexte, l’application de règles, la génération d’une réponse et, éventuellement, le recours à des services ou outils supplémentaires. Chacune de ces étapes peut réussir ou échouer indépendamment des autres et être soumise à différentes contraintes, telles que des seuils de latence, des limites de coûts ou des exigences réglementaires.
Cela signifie que la disponibilité ne dépend plus seulement de l’accessibilité d’un point de terminaison. Elle dépend de la capacité du système à exécuter correctement l’ensemble de la chaîne de décisions nécessaire pour traiter la requête.
Il est possible d’avoir un système dont tous les composants sont techniquement opérationnels, mais dont l’application est incapable de fournir une réponse. Un modèle peut être disponible, mais interdit pour un jeu de données donné. Une étape de récupération peut renvoyer des données qui ne peuvent pas être utilisées en raison d’une politique en vigueur. Un agent peut démarrer un workflow sans pouvoir le mener à bien parce qu’une action requise est bloquée.
Cela crée un autre type de défi en matière de disponibilité. Le basculement traditionnel suppose que vous pouvez rediriger la requête ailleurs. Dans les systèmes d’IA, il faut souvent trouver une autre façon d’accomplir la tâche. Cela nécessite une prise de décision dynamique au niveau de la couche de diffusion, et pas seulement une redondance de l’infrastructure.
Impact sur l’évolutivité
L’article d’origine souligne la difficulté de faire évoluer des applications qui reposent sur des intégrations sur mesure. Chaque dépendance supplémentaire accroît la complexité, et le passage à l’échelle nécessite souvent des efforts de développement supplémentaires pour gérer efficacement ces intégrations. L’IA amplifie ce phénomène, car elle repose intrinsèquement sur la composition.
Une application basée sur l’IA peut s’appuyer sur plusieurs modèles, bases de données vectorielles, API et sources de données externes. La combinaison de ces éléments n’est pas figée. Elle peut varier en fonction de la requête, de l’utilisateur ou du contexte. Cette variabilité devient le principal facteur déterminant de la capacité à passer à l’échelle.
La mise à l’échelle ne consiste plus seulement à traiter davantage de requêtes par seconde. Il s’agit de gérer davantage de combinaisons de comportements pour chaque requête.
Si chaque variante doit être implémentée dans le code de l’application, le système devient rapidement ingérable. Les modifications deviennent risquées, les déploiements ralentissent et l’application se transforme en un assemblage disparate de logiques conditionnelles.
La même solution que pour les applications traditionnelles devient donc encore plus importante. Il faut transférer cette variabilité de l’application vers la couche de diffusion. Les décisions de routage s’étendent alors à des décisions d’orchestration. L’insertion de services devient une composition dynamique. La couche de diffusion se charge de sélectionner la combinaison de composants appropriée pour traiter chaque requête.
Sans ce changement, la capacité de mise à l’échelle s’effondre sous le poids de sa propre complexité.
Impact sur l’efficacité opérationnelle
Les exigences sur mesure ont toujours alourdi la charge opérationnelle. Chaque exception nécessite une maintenance. Chaque personnalisation introduit un nouveau point de défaillance. Au fil du temps, cela aboutit à un système plus difficile à gérer et plus lent à faire évoluer. C’est ce qu’on appelle la dette opérationnelle, et l’IA en accélère l’accumulation.
Le système ne se contente plus de gérer des parcours prédéfinis : il les génère. Différentes invites peuvent déclencher différents parcours d’exécution. Les agents peuvent enchaîner des actions d’une manière qui n’a pas été explicitement conçue à l’avance. De nouveaux modèles et services sont régulièrement introduits, chacun avec ses propres caractéristiques et contraintes.
Cela génère un flux constant de variations que les équipes opérationnelles doivent prendre en compte.
Si la seule façon de gérer cette variabilité consiste à modifier le code de l’application ou à mettre à jour des configurations statiques, le système devient fragile. Les équipes passent leur temps à réagir aux cas particuliers au lieu de gérer le système dans son ensemble. Des incohérences apparaissent entre les environnements. Le comportement dérive.
L’efficacité opérationnelle dépend donc de votre capacité à centraliser le contrôle de cette variabilité. La couche de diffusion doit agir comme une force stabilisatrice, en absorbant les différences et en appliquant des politiques cohérentes à l’ensemble d’un système par ailleurs dynamique. Sans cela, le sur-mesure tourne rapidement au chaos.
Bonnes pratiques pour gérer les exigences sur mesure
La programmabilité comme fonctionnalité de premier plan
La programmabilité reste essentielle pour répondre aux exigences spécifiques, qu’elles concernent l’IA, des technologies traditionnelles, modernes ou <insérez ici la prochaine génération>. Au lieu de coder la logique en dur dans les applications, vous introduisez dans le chemin de diffusion une couche programmable capable de s’adapter aux différents besoins.
Avec l’IA, cela devient essentiel, car les systèmes d’IA évoluent rapidement. De nouveaux modèles sont introduits, les politiques changent, les sources de données évoluent et de nouveaux schémas d’interaction émergent. Il est impossible d’anticiper tout cela dès la phase de conception, et vous ne pouvez pas vous permettre de reconstruire les applications à chaque changement.
Une couche de diffusion programmable vous permet de vous adapter sans tout reconstruire. Vous pouvez inspecter les requêtes, appliquer un routage tenant compte du contexte, modifier les entrées et les sorties, et ajouter ou supprimer des services selon les besoins. Plus important encore, vous pouvez le faire de manière cohérente dans toutes les applications.
C’est là que la mise à disposition des applications commence à s’apparenter moins à de la tuyauterie et davantage à un plan de contrôle. Il ne s’agit pas simplement d’acheminer le trafic, mais de façonner le comportement du système.
L’orientation du trafic devient un routage décisionnel
La distribution traditionnelle des applications consiste à acheminer le trafic vers la bonne destination. Jusqu’à présent, la question était toujours : « Où cette requête doit-elle être dirigée ? » Avec l’IA, elle devient plus nuancée : « Quelle est la meilleure façon de répondre à cette requête ? »
Cela implique parfois de choisir entre plusieurs modèles en fonction des exigences de latence, de coût ou de conformité. Il peut aussi s’agir d’enrichir la requête avec du contexte supplémentaire avant de l’envoyer à un modèle. Dans certains cas, cela signifie contourner entièrement l’IA et acheminer la requête vers un service déterministe capable de fournir une réponse plus précise ou plus conforme.
La décision ne porte plus seulement sur l’emplacement. Elle porte sur l’exécution.
Cette évolution fait du routage une fonction de plus haut niveau. Il lui incombe désormais de sélectionner le chemin que suivra la requête parmi un ensemble de capacités possibles. Cela signifie également que la couche de distribution doit disposer d’une visibilité allant au-delà des seules conditions du réseau. Elle doit connaître les politiques, le contexte et les résultats attendus.
Il s’agit d’un prolongement naturel de ce qu’ADC09 a toujours défendu. Lorsque les applications ont des exigences spécifiques, la couche de distribution doit s’adapter. L’IA ne fait que porter cette adaptation à un niveau supérieur.
Conclusion
La programmabilité en tant que fonctionnalité a toujours reposé sur une vérité simple : les applications ne sont pas uniformes et l’infrastructure doit s’adapter à leurs différences. Cette vérité reste inchangée.
L’IA ne fait qu’accroître à la fois la fréquence et la complexité de ces différences. Les systèmes deviennent plus dynamiques, plus modulaires et plus dépendants des décisions prises lors de l’exécution. L’idée d’un parcours applicatif « standard » devient plus difficile à défendre.
La réponse reste la même que depuis toujours, mais elle est plus urgente.
Vous avez besoin d’une couche de diffusion programmable. Vous devez pouvoir contrôler de manière centralisée la façon dont les requêtes sont traitées, acheminées et exécutées. Et vous devez pouvoir vous adapter à de nouvelles exigences sans avoir à réécrire les applications à chaque changement.
Car, dans une architecture pilotée par l’IA, le sur-mesure n’est plus une exception autour de laquelle vous concevez votre système.
C’est le modèle opérationnel autour duquel vous concevez votre architecture.
En savoir plus sur les 10 principaux défis liés à la livraison d’applications auxquels sont confrontées les organisations du monde entier.
À 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
Top 10 des risques liés à la mise en production d’applications d’IA : manque de sécurité et de conformité réglementaire
L’IA étend la conformité au-delà de la sécurisation des chemins d’accès et des espaces de stockage pour englober la gouvernance du comportement à l’exécution — accès aux modèles, contexte de récupération, résultats et actions des agents —, de sorte que les contrôles doivent être rapprochés de l’inférence.
Qu’est-ce que le Top 10 de la distribution d’applications ?
F5 entend aider les organisations à relever les défis liés à la mise à disposition et à la sécurisation des applications, des API et de l’IA générative grâce à la liste des 10 principales priorités en matière de mise à disposition des applications.
Top 10 de la livraison d’applications d’IA : politiques de livraison incompatibles
Les divergences de politiques deviennent des sources de pannes pour l’IA : des mécanismes de basculement, des délais d’expiration, des limites et des contrôles de sécurité incohérents entraînent des défaillances silencieuses, des résultats partiels et des résultats différents selon le point de terminaison.
Top 10 de la livraison d’applications d’IA : incapacité à gérer la latence
Avec l’IA, la latence devient un enjeu de confiance, et plus seulement de performance : les réponses lentes d’un « assistant » donnent une impression d’hésitation ou d’échec, tandis que les requêtes et réponses riches en tokens alourdissent la charge, même sur des systèmes en parfait état de fonctionnement.
Top 10 de la mise à disposition d’applications d’IA : orientation du trafic non optimisée
L’IA remet en cause les principes traditionnels de répartition du trafic : les backends ne sont pas interchangeables, les coûts varient et les agents multiplient les requêtes de manière imprévisible. Le routage doit donc tenir compte du modèle, de l’état des GPU et de la localisation des données.
Top 10 de la livraison d’applications d’IA : contrôles du trafic insuffisants
Les limites de débit et les mécanismes de régulation traditionnels ne tiennent pas compte de l’étendue réelle des répercussions. Les charges de travail d’IA se répartissent entre les modèles, les bases de données vectorielles et les services, provoquant des pics de latence, des défaillances en cascade et des nouvelles tentatives.