Votre agent IA chez Elevare Digital est passé en mode veille parce qu'une nouvelle politique de sécurité au niveau des lignes (RLS) PostgreSQL a filtré toutes les lignes de tâches, faisant apparaître la file d'attente comme vide. L'erreur est passée inaperçue jusqu'à ce que les tâches s'accumulent, forçant l'équipe à repenser la manière dont l'orchestrateur détecte une file d'attente vide.
L'angle mort caché
ARIA, le système d'IA autonome d'Elevare, interroge une table PostgreSQL pour les tâches en attente. La requête a réussi, a renvoyé zéro ligne, et l'agent s'est endormi. En réalité, la table était pleine. Une politique RLS limitait l'accès SELECT à un ensemble spécifique d'utilisateurs. L'orchestrateur s'est connecté avec un rôle de service qui ne possédait pas le privilège de contournement (bypass), de sorte que la base de données a silencieusement supprimé chaque ligne du jeu de résultats. PostgreSQL traite une lecture filtrée de la même manière qu'une table vide ; aucun code d'erreur, d'avertissement ou d'échec n'est donc apparu. Un signal de vie (heartbeat) sain de l'agent inactif n'a laissé présager aucun problème.
Comment la RLS a transformé une file d'attente pleine en silence
La RLS ajoute un prédicat à chaque ligne lors d'un SELECT. Si le prédicat est faux, la ligne disparaît du résultat. Le client ne voit que les lignes qui satisfont la politique ; il ne sait jamais que des lignes ont été masquées. Pour un gestionnaire de file d'attente (queue worker), un jeu de résultats vide ressemble exactement à une file d'attente réellement vide. L'orchestrateur a supposé que « pas de lignes = pas de travail » et est entré dans sa boucle d'inactivité pendant que les tâches s'accumulaient en coulisses.
L'équipe a découvert qu'une politique destinée à limiter les lectures à des utilisateurs individuels avait involontairement inclus le rôle de service lui-même. Comme le rôle ne possédait pas l'attribut spécial « bypass RLS », la politique s'appliquait à chaque requête émise par l'orchestrateur. Cela illustre un compromis classique entre sécurité et observabilité : la RLS protège les données des utilisateurs non autorisés, mais elle supprime également un signal d'échec utile pour les composants système qui dépendent de la visibilité.
Le modèle de vérification par « canari » (canary-check)
Pour rompre la dépendance à un résultat vide et silencieux, Elevare a ajouté une vérification « canari ». Le nouveau flux est le suivant :
- Interroger la table des tâches en attente.
- Si des lignes sont renvoyées, les traiter comme auparavant.
- Si le résultat est vide, effectuer une seconde requête sur une ligne « canari » dédiée qui doit toujours exister.
- Si la requête canari renvoie la ligne attendue, la file d'attente est réellement vide ; enregistrer un signal de vie (heartbeat) d'inactivité.
- Si la requête canari ne renvoie rien non plus, l'agent est aveugle ; déclencher une alerte immédiate.
Désormais, l'orchestrateur distingue trois états :
- Tâches trouvées – traitement normal.
- Pas de tâches, canari OK – période d'inactivité réelle.
- Pas de tâches, échec du canari – blocage RLS caché, déclenchement de l'alerte.
La table canari est une ligne unique qui ne change jamais. Sa mise en place a pris environ une heure, mais elle élimine toute une classe d'échecs silencieux.
Ce que les équipes devraient faire
Si vous gérez des gestionnaires de file d'attente sur PostgreSQL ou un service hébergé basé sur celui-ci (tel que Supabase), suivez ces étapes :
- Utilisez un identifiant de rôle de service (service-role) avec le flag « bypass RLS ». Cela permet aux composants système de voir toutes les lignes, quelles que soient les politiques au niveau de l'utilisateur.
- Auditez les politiques RLS pour vérifier l'absence de permissions de contournement pour les rôles de service. Une politique qui semble correcte pour les utilisateurs finaux peut involontairement piéger les services internes.
- Ajoutez une table canari (ou une ligne équivalente toujours présente) et incorporez la vérification canari dans la logique d'inactivité du gestionnaire. La requête supplémentaire est peu coûteuse et constitue un filet de sécurité clair.
Le compromis
La RLS reste un outil puissant pour appliquer un contrôle d'accès aux données granulaire. Elle empêche les fuites de données accidentelles et prend en charge les architectures multi-tenant sans éparpiller des filtres au niveau de l'application dans tout le code source. L'inconvénient est qu'elle peut masquer des échecs pour les composants qui attendent qu'un simple signal « aucune ligne » signifie « rien à faire ». Le modèle canari ne fragilise pas la RLS ; il ajoute une étape de vérification légère qui restaure l'observabilité.
À retenir
Une politique RLS cachée peut transformer une file d'attente active en une impasse silencieuse, laissant les agents IA inactifs alors que le travail s'accumule. Accordez aux rôles de service le privilège de contournement approprié et associez chaque lecture de file d'attente vide à une vérification canari ; les équipes pourront ainsi garantir l'intégrité de leurs travailleurs autonomes et éviter des angles morts coûteux.