Comment créer une couche de plugins pour les workflows LLM sans transformer les applications en code de liaison

Le coût caché du code de liaison au niveau applicatif

Les workflows IA se développent par accumulation. Une équipe commence avec un simple appel de complétion. Elle ajoute ensuite un template de prompt. Puis une étape de rédaction des données sensibles, une tentative de relance, un parseur JSON, un contrôle de sécurité, une étiquette d’usage et un callback. Une autre équipe répète le même schéma avec un fournisseur différent et une implémentation légèrement différente.

Au départ, cela ressemble à du code applicatif normal. Avec le temps, cela devient de l’infrastructure dispersée dans chaque service. La même politique existe en cinq versions. La validation des sorties varie d’une équipe à l’autre. Les journaux sont incohérents. Les migrations de fournisseurs nécessitent des changements dans des dépôts qui n’ont rien à voir.

• La préparation des prompts est dupliquée entre les services.
• La validation des sorties est gérée différemment par chaque équipe.
• Les contrôles de sécurité dépendent de la rigueur de chaque implémentation locale.
• Les indications de routage sont enfouies dans le code applicatif.
• La réponse aux incidents exige de lire plusieurs wrappers personnalisés.

Ce qui appartient à une couche de plugins au niveau de la passerelle

Une couche de plugins doit contenir les comportements réutilisables, guidés par des politiques ou importants sur le plan opérationnel. Elle ne doit pas devenir un fourre-tout pour la logique métier propre au produit, mais elle doit absorber les préoccupations communes aux workflows IA qui finissent autrement par être copiées partout.

Les bons candidats incluent la validation des requêtes, l’enrichissement des prompts, la rédaction des données sensibles, la validation de schéma, la transformation des réponses, les tags d’audit personnalisés, les indications de routage, les portes d’approbation et les callbacks d’intégration. Ce sont des préoccupations transverses. Elles deviennent plus fiables lorsqu’elles vivent dans le même chemin que le routage, les budgets, les garde-fous et l’observabilité.

Les plugins avant l’appel au modèle

Les plugins pré-appel préparent et protègent la requête avant qu’elle n’atteigne un fournisseur. Ils peuvent rejeter des payloads mal formés, ajouter des métadonnées de tenant, masquer des champs sensibles, appliquer des listes de modèles autorisés ou ajouter des indications de routage selon le type de charge de travail.

C’est aussi l’endroit où les équipes peuvent appliquer des contrôles trop spécifiques pour des garde-fous génériques. Par exemple, un workflow de santé peut devoir empêcher certains champs de sortir d’une région. Un workflow de support peut devoir exiger un identifiant client. Un assistant de code peut devoir supprimer des secrets collés dans des journaux.

Lorsque cette logique se trouve dans la passerelle, chaque application utilisant la même clé virtuelle ou la même route hérite du même comportement.

Les plugins après la réponse du modèle

Les plugins post-appel sont tout aussi importants. Ils peuvent valider du JSON, imposer des exigences de citation, classifier le risque d’une réponse, transformer une sortie propre à un fournisseur en format interne ou déclencher un parcours de revue lorsque la confiance est faible.

Cela évite aux systèmes en aval de traiter chaque réponse du modèle comme fiable par défaut. Cela rend aussi les déploiements de modèles plus sûrs, car la validation peut rester stable pendant que le fournisseur change derrière la passerelle.

Pour les agents dotés d’outils, les plugins post-appel peuvent inspecter les arguments d’outil proposés avant exécution ou enregistrer des métadonnées d’audit après la fin d’un outil.

Garder le comportement des plugins observable

Les plugins ne doivent pas devenir un middleware invisible. Les opérateurs doivent savoir quels plugins se sont exécutés, combien de temps ils ont pris, quelles décisions ils ont prises et s’ils ont modifié la requête ou la réponse. Sinon, le débogage devient de la devinette.

La passerelle doit enregistrer les résultats des plugins aux côtés du fournisseur, du modèle, de la clé virtuelle, de l’usage des tokens, de la latence et des décisions de garde-fous. Les équipes peuvent ainsi voir si une requête lente vient du fournisseur, d’un plugin, d’un outil ou de l’application elle-même.

Comment Odock utilise les plugins dans le plan de contrôle

Le positionnement d’Odock inclut un moteur de plugins extensible pour la validation, les transformations et les workflows personnalisés. C’est important, car l’infrastructure IA doit rester flexible sans devenir fragmentée.

La meilleure architecture de plugins donne aux équipes produit de la marge pour personnaliser les comportements tout en conservant les contrôles essentiels au centre. Les applications ne devraient pas avoir besoin de connaître chaque particularité de fournisseur, chaque règle de sécurité ou chaque exigence de journalisation. Elles devraient envoyer leurs requêtes à un endpoint unique et laisser la passerelle appliquer le bon workflow autour d’elles.

La règle de conception pratique

Si un morceau de logique de workflow IA doit rester cohérent entre les équipes, être visible lors des incidents ou pouvoir changer sans redéployer chaque application, il appartient probablement près de la passerelle. S’il est profondément spécifique à une fonctionnalité produit, il peut rester dans l’application.

Cette frontière garde le système maintenable. Les équipes produit conservent leur logique fonctionnelle. Les équipes plateforme conservent le plan de contrôle IA partagé. Et tout le monde évite de reconstruire encore et encore le même code de liaison.