Un chat de support peut se transformer en une opération impliquant un transfert d’argent lorsqu’un backend FastAPI accepte la sortie d’un modèle comme une instruction faisant autorité.
Dans le scénario de défaillance utilisé pour ce cours, une application cliente envoie un message d’apparence anodine à POST /v1/chat ; le service FastAPI transmet ce texte à un fournisseur de modèle, et le modèle renvoie une instruction d’outil ressemblant à une demande de remboursement.
Le backend exécute l’appel d’outil dès que le modèle le suggère, sans vérifier si l’utilisateur final est autorisé à effectuer cette action et sans traiter la sortie du modèle comme du texte non fiable.
Aucun élément inhabituel n’est nécessaire pour provoquer cette défaillance. Le backend fait exactement ce pour quoi il a été conçu, mais il exécute l’étape la plus critique — l’action de l’outil — en se basant sur une chaîne de caractères provenant de l’extérieur de la limite de confiance.
Une fois l’action irréversible exécutée, aucun filtre ultérieur ne peut annuler l’effet secondaire ; il faut donc déterminer où placer le premier point d’arrêt efficace.
Une même requête traverse plusieurs limites où du texte non fiable se transforme en dépenses ou en effets secondaires ; le cours se concentre sur ce chemin unique afin que chaque mécanisme de contrôle soit situé à un endroit précis.
Du texte non fiable peut pénétrer le système depuis trois sources, même lorsque l’appelant se comporte correctement : le message de l’appelant contenu dans la requête HTTP, les documents récupérés depuis les propres magasins de données du backend, et les résultats d’outils provenant d’autres systèmes potentiellement erronés ou malveillants.
Des ressources (argent et données) peuvent être consommées à deux niveaux : l’appel au fournisseur de modèle entraîne une consommation de jetons et des coûts, tandis que l’exécution de l’outil peut lire ou modifier des ressources réelles dont l’utilisateur n’est pas nécessairement propriétaire.
Les seuls points de contrôle fiables sont les vérifications côté serveur effectuées par le service FastAPI autour de ces points de consommation de ressources. Le cours met en place l’authentification, l’association au locataire (tenant binding), les quotas, les filtres d’entrée et de sortie, l’autorisation d’utilisation des outils, le bac à sable (sandboxing) et la journalisation d’audit sous forme de barrières explicites ; la formulation du prompt ne garantit aucune de ces mesures, car le prompt système est lisible et le modèle se contente de suivre le texte.
Le schéma ci-dessous indique chaque entrée non fiable et chaque point de contrôle sur le cheminement unique de la requête que nous continuons d’explorer. Identifions précisément le moment où le texte acquiert une valeur d’instruction faisant autorité et où nous pouvons refuser l’opération.
Ce diagramme met en évidence une règle. Toute flèche portant du texte provient d’une source non fiable ; seuls les blocs de notre service peuvent refuser, plafonner, valider, autoriser et consigner les événements.
Un contrat d’API sécurisé nécessite des codes de refus cohérents, car les clients comme les équipes de débogage d’astreinte ont besoin de résultats prévisibles lorsqu’un point de contrôle rejette une requête.
Nous définissons ce référentiel de refus une seule fois et le réutilisons, en associant systématiquement chaque refus à la limite qui l’applique plutôt qu’au modèle lui-même.
401 Unauthorized : rejette les identifiants de l’appelant s’ils sont manquants, invalides, révoqués ou compromis ; le service renvoie cette erreur avant de consommer le quota ou d’appeler le fournisseur.403 Forbidden : rejette un appelant authentifié agissant hors de son périmètre autorisé (y compris en cas d’approbation refusée ou expirée) ; ce code rejette également les tentatives d’accès à un outil dont la destination est bloquée (laquelle n’est jamais contactée).422 Unprocessable Content (RFC 9110) : rejette la sortie du modèle si elle échoue à la validation de schéma, car une sortie non validée n’est que du texte tant que le serveur n’a pas prouvé sa conformité au contrat de l’outil.429 Too Many Requests (avec en-tête Retry-After) : signale l’épuisement de la limite de débit ou du quota ; le compteur doit être partagé pour éviter que les répliques ne multiplient silencieusement la limite autorisée.503 Service Unavailable : renvoyé lorsque le système de stockage des quotas est hors service ou qu’un disjoncteur ouvert empêche l’application des règles, le service ne pouvant alors déterminer en toute sécurité si la consommation est autorisée.504 Gateway Timeout : renvoyé lorsque l’appel au fournisseur dépasse le délai d’attente du service, car les appels en attente indéfinie représentent une consommation incontrôlée.Pour rendre le cours concret, nous développons un artefact fonctionnel que nous renforçons étape par étape. Cet artefact consiste en une route POST /v1/chat prenant en compte le locataire (tenant) et capable d’appeler un seul outil ; chaque leçon ultérieure ajoute un point de contrôle supplémentaire à ce flux.
Dans le cas d’une défaillance initiale, l’appelant peut être légitime : l’authentification réussit alors, mais la requête déclenche tout de même une action non autorisée via l’outil.
Si le service attend l’exécution de l’appel à l’outil pour valider la sortie du modèle, la validation de schéma peut certes rejeter une charge utile mal formée, mais elle ne peut pas annuler une action apparemment correcte qui n’aurait jamais dû être autorisée.
La décision cruciale consiste à déterminer quelle étape est en mesure de refuser l’opération avant l’exécution d’une action irréversible de l’outil. Quel est le premier point d’arrêt permettant de bloquer la défaillance : l’authentification, l’autorisation d’utilisation de l’outil ou la validation du résultat ?