Retool RBAC et journaux d'audit : évaluer Retool pour des applis IA gouvernées

TL;DR : Si vous évaluez Retool pour le développement d’applis IA gouvernées, sa couche d’accès passe l’examen, et il ne faut pas faire semblant du contraire. Retool propose du RBAC via des groupes de permissions, un contrôle par rôle de qui peut utiliser son constructeur IA, des journaux d’audit qui enregistrent chaque exécution de requête, le SSO, l’auto-hébergement et (depuis octobre 2026, en bêta publique pour Postgres) des politiques d’accès aux ressources auxquelles aucune requête ne peut se soustraire. Depuis juin 2026, il applique aussi ces contrôles aux applis construites dans Lovable, Cursor ou Claude Code. Ce qu’il ne vous donne pas, c’est l’autorité métier comme fait déclaré. « Cette personne peut-elle émettre un remboursement de 12 000 $ ? » vit encore le plus souvent dans du JavaScript éparpillé entre les propriétés des composants et la logique des requêtes, et une IA écrit ces expressions plus vite qu’aucune pull request ne peut les relire. La faille n’est pas la sécurité de base. C’est que l’autorité est du code, et non une règle qu’un relecteur peut lire en un seul endroit.

Imaginez l’appli Retool la plus banale du monde : une console de remboursement. Un ingénieur la construit en un après-midi — une table de commandes, un bouton « Rembourser », quelques requêtes. Le support s’en sert. C’est formidable. C’est Retool au sommet de son art, et Retool est vraiment le meilleur de la catégorie là-dessus.

Six mois plus tard. L’ingénieur qui l’a construite a changé d’équipe. La sécurité mène une revue d’accès et pose au nouveau responsable une question d’une ligne : « Quels rôles peuvent émettre un remboursement de plus de 10 000 $, et où exactement est-ce appliqué ? »

Regardez ce que le nouveau responsable doit faire pour répondre. Il n’y a pas un seul endroit où regarder. Il ouvre l’appli et se met à lire du JavaScript.

Le test du grep

Voici ce à quoi ressemble réellement « où est-ce appliqué » dans une vraie appli Retool. L’autorité d’émettre un gros remboursement est répartie sur au moins trois expressions indépendantes, chacune écrite à la main, chacune d’une forme différente :

// 1. refundButton → propriété "Hidden"
{{ current_user.groups.map(g => g.name).includes('admin') ||
   (current_user.groups.map(g => g.name).includes('support_lead') && refundAmount.value <= 10000) }}

// 2. refundAmount input → propriété "disabled"
{{ !current_user.groups.map(g => g.name).includes('support_lead') }}

// 3. issueRefund query → transformer (c'est la partie qui écrit réellement)
if (refundAmount.value > 10000 && !current_user.groups.map(g => g.name).includes('finance')) {
  throw new Error('Refunds over $10k require finance');
}

Trois endroits. Trois conditions subtilement différentes. Le bouton se cache pour certains utilisateurs ; le champ se désactive pour d’autres ; la requête lève une erreur pour un troisième ensemble. Elles sont censées s’additionner en une règle cohérente — « les support leads jusqu’à 10 000 $, finance au-dessus » — mais rien ne garantit que c’est le cas. Cachez un bouton et la requête sous-jacente s’exécute quand même si quelqu’un l’atteint autrement. Ajoutez un deuxième chemin d’écriture le trimestre prochain en oubliant le contrôle finance, et vous avez une faille qu’aucun écran ne révèle.

Appelez ça le test du grep : pour répondre à « qui peut faire X », lisez-vous une règle déclarée, ou devez-vous faire un grep sur l’appli ? Si c’est grep, l’appli n’est pas gouvernée au niveau de l’autorité — elle est simplement codée, et la gouvernance d’accès (que Retool maîtrise parfaitement) se situe une couche au-dessus de ce qui peut réellement vous faire du mal.

Par contraste, voici la même autorité sous forme de fait déclaré — une règle que le runtime applique sur chaque chemin, peu importe par quel bouton ou quelle requête vous êtes arrivé :

action: issue_refund
  who_can_run:
    - role: SupportLead   when: amount <= 10000
    - role: Finance       when: amount  > 10000
  requires_approval:      when: amount > 10000      # une barrière préventive, pas une erreur levée
  audit: always

Un seul endroit à lire. Un seul endroit à modifier. Une seule chose sur laquelle un relecteur — ou une IA — doit raisonner. La différence entre trois expressions entretenues à la main et une règle déclarée, c’est toute la différence entre « l’appli est codée » et « l’autorité de l’appli est gouvernée ».

Retool RBAC et journaux d’audit : ce que couvre réellement chaque contrôle

Le test du grep n’est équitable que si les contrôles que Retool possède bel et bien sont énoncés exactement. Les voici, vérifiés dans la documentation de Retool elle-même en novembre 2026 :

Contrôle	Ce qu’il gouverne	Où il s’arrête
Groupes de permissions (RBAC)	Les groupes « attribuent des rôles et contrôlent l’accès aux applis, ressources, workflows et agents » (guides des permissions Retool)	Qui peut ouvrir, modifier ou interroger, pas ce qu’une action donnée peut faire une fois quelqu’un à l’intérieur
Assist RBAC (févr. 2026, Business et Enterprise)	Par rôle : modes Ask et Build, mode Ask seul, ou aucun accès au constructeur IA (changelog)	Qui peut générer des changements, pas ce qu’un changement généré accorde
Journaux d’audit	Les actions des utilisateurs, « telles que les exécutions de requêtes et les réinitialisations de mot de passe », avec la requête exacte, les paramètres, l’adresse IP et le temps de réponse ; un an de rétention sur Cloud, export CSV en Business et Enterprise, streaming vers Datadog ou Splunk en Enterprise (journaux d’audit)	Détective : ils enregistrent ce qui s’est exécuté, une fois exécuté
Filtres de lignes current_user	Des valeurs « calculées côté serveur à partir de la session authentifiée » et injectées dans chaque requête (sécurité au niveau des lignes)	Requête par requête, à la main : « Une requête qui omet le filtre renvoie des données non filtrées. »
Politiques d’accès aux ressources	Accès aux tables, colonnes et lignes d’une ressource, appliqué à chaque requête venant des applis, de la bibliothèque de requêtes, du SQL brut et des agents (politiques d’accès)	PostgreSQL uniquement, en bêta publique depuis octobre 2026 ; les filtres de lignes « ne valident ni les lignes qu’un utilisateur crée, ni les valeurs qu’un utilisateur écrit »
Gouvernance des applis codées par IA (juin 2026)	Les applis construites dans Lovable, Replit, Cursor ou Claude Code « héritent des permissions et des pistes d’audit existantes » ; « Les permissions sont rattachées aux sources de données » (salle de presse Retool)	Même couche : permissions sur les sources de données, pas des règles métier au niveau de l’action

Deux de ces lignes comptent plus que les autres, parce qu’on y voit Retool aller exactement dans la direction que défend cet article.

Les politiques d’accès sont une règle déclarée, pas trois expressions. Une politique sur la ressource s’applique à chaque requête, « si bien qu’aucune requête ne peut s’y soustraire », soit l’inverse du filtre current_user posé requête par requête. Pour l’autorité sur les données — quelles lignes un support lead peut lire ou supprimer —, cela règle l’essentiel du test du grep sur Postgres. La mise à jour honnête par rapport à la version de juin de cet article, c’est que Retool a désormais une vraie réponse pour cette couche.

Ce que les politiques n’expriment pas, c’est la règle de remboursement. La documentation des politiques d’accès décrit l’accès en lecture, écriture et suppression aux tables, colonnes et lignes. Elle ne décrit ni seuils de montant, ni barrières d’approbation, ni conditions sur la valeur écrite ; et les filtres de lignes ne vérifient explicitement pas ce qu’un utilisateur écrit. « Les support leads jusqu’à 10 000 $, la finance au-delà, une approbation au-dessus du seuil » est une règle sur une action et ses arguments : elle vit donc toujours dans le bouton, le champ et le transformer ci-dessus. Les politiques ramènent l’autorité sur les données en un seul endroit. L’autorité métier reste dans le JavaScript.

Lisez le tableau comme une grille d’évaluation, et Retool réussit chaque question de gouvernance d’accès qu’une revue de sécurité posera. Celle à laquelle il ne peut pas répondre depuis un seul endroit, c’est celle du début de cet article : quels rôles peuvent émettre un remboursement de plus de 10 000 $, et où est-ce appliqué ?

Pourquoi le contrôle de version ne comble pas cette faille

L’objection de l’ingénieur Retool averti est juste, et il faut y répondre précisément : « Nous avons un contrôle de version adossé à Git, des journaux d’audit et du RBAC. Les changements sont relus en PR. L’accès est gouverné. Que manque-t-il ? »

Trois choses, précisément.

Premièrement, une PR sur une appli Retool est une revue de JavaScript et de bindings éparpillés entre les composants — vous faites de la relecture de code, ce qui signifie que (a) cela exige un ingénieur, et (b) il n’existe aucune représentation structurée de « ce changement a modifié qui peut émettre un gros remboursement. » Le relecteur doit remarquer qu’un ajustement à une expression Hidden trois composants plus loin a déplacé une frontière d’autorité. Les diffs de logique éparpillée cachent précisément ce que vous avez le plus besoin de voir.

Deuxièmement, le contrôle de version relit du code, pas l’autorité comme un fait. « Cette PR a-t-elle changé qui peut rembourser plus de 10 000 $ ? » n’est pas une question à laquelle un diff Git répond directement ; c’est une question à laquelle vous répondez en traçant le code dans votre tête. La règle déclarée ci-dessus rend ce diff trivial : who_can_run a changé, ou non.

Troisièmement — et c’est ce qui compte le plus pour la direction que prend l’industrie — toute la prémisse du low-code, c’est que les non-ingénieurs et l’IA modifient l’appli, souvent dans l’éditeur visuel, souvent sans aucune PR. La gouvernance sur laquelle vous comptez (la relecture de PR) n’existe pas pour les changements pour lesquels le low-code est fait. Les journaux d’audit vous diront qu’une propriété Hidden a changé, après coup — détective, pas préventif — mais personne n’a relu quelle autorité elle accordait avant la mise en production.

L’IA ne casse pas ça. Elle le multiplie.

Pendant des années, le test du grep était survivable parce qu’un humain écrivait le JavaScript et qu’un autre humain portait la connaissance de l’endroit où vivait chaque règle. La logique éparpillée est navigable si une personne l’a construite et s’en souvient.

Pointez une IA sur la même appli et l’économie s’inverse dans les deux sens. L’IA peut générer cinquante bindings et une douzaine de transformers en une minute — elle produit des décisions d’autorité plus vite qu’aucun relecteur ne peut les tracer. Et pour relire ce qu’elle a produit, vous revoilà à lire du JavaScript à travers les écrans, parce qu’il n’existe toujours aucune représentation structurée unique de l’autorité à comparer en diff. « Retool AI » et les Agents (2025) sont réels et utiles, mais ils automatisent par-dessus le même substrat bâti à la main : l’agent est gouverné (Retool peut cadrer ce qu’il appelle), mais l’appli que l’agent modifie ne l’est pas — pas gouvernée en autorité sous une forme qu’une IA — ou un humain — puisse relire comme un fait plutôt que comme du code.

Ce que l’IA produit le plus vite est précisément ce que Retool rend le plus difficile à relire.

Retool vs. Lovable pour les applis d’entreprise

L’autre comparaison que l’on fait souvent oppose Retool à Lovable, généralement présentée comme « constructeur d’outils internes vs. générateur d’applis IA ». Pour une appli d’entreprise, le cadrage le plus utile est : les utilisateurs de qui chaque contrôle gouverne-t-il ?

	Retool	Lovable
Ce que l’IA produit	Une appli sur le runtime de composants de Retool, branchée sur vos ressources existantes	Du code de projet full-stack ; par défaut, il « vit dans l’infrastructure managée de Lovable », avec synchronisation vers GitHub, GitLab ou Bitbucket (Lovable for Enterprise)
Rôles	Les groupes de permissions contrôlent l’accès à l’appli et aux ressources, workflows et agents qui se trouvent derrière	Propriétaire, admin, éditeur, lecteur et collaborateur externe gouvernent l’espace de travail qui construit l’appli (même page)
Accès des utilisateurs finaux aux données	Permissions des sources de données, filtres current_user, politiques d’accès	Sécurité au niveau des lignes dans le backend intégré « pour les données par utilisateur », intégrée au projet généré ; un Quick scan « s’exécute à chaque publication et vérifie les règles d’accès à la base de données »
Audit	Journal d’audit au niveau des requêtes, un an sur Cloud	Journal d’audit de l’espace de travail « conservé 13 semaines », avec export planifié vers un SIEM ou un bucket de stockage
Auto-hébergement	Instances auto-hébergées gérées par Retool ou autogérées (Retool auto-hébergé)	Le backend et la base de données peuvent passer sur une infrastructure que vous exploitez, « y compris Supabase auto-hébergé » ; le constructeur lui-même reste en SaaS

La distinction des deuxième et troisième lignes est celle qui décide de l’adéquation à l’entreprise. Les rôles et le journal d’audit de Lovable gouvernent les personnes qui construisent l’appli ; les personnes qui l’utilisent sont protégées par les règles d’accès du backend propre au projet généré, qu’un scan vérifie à chaque publication. Retool gouverne les personnes qui utilisent l’appli, parce que l’appli tourne dans Retool. C’est pourquoi le mouvement de Retool en juin 2026 consiste à héberger les applis construites dans Lovable et des outils similaires sous ses propres permissions de sources de données, plutôt qu’à les concurrencer sur la génération.

Le schéma réaliste en entreprise n’est donc pas « Retool ou Lovable », mais « générer n’importe où, exécuter dans un lieu gouverné ». Aucun des deux ne change le test du grep : le seuil de remboursement d’une appli Lovable vit dans son code généré, celui d’une appli Retool dans ses bindings et ses transformers, et dans les deux cas un relecteur reconstitue l’autorité métier en lisant du code.

Là où Retool est le bon choix — et là où le modèle de métadonnées vous coûte

Soyez honnête dans les deux sens, car un texte à sens unique ne vaut rien pour quelqu’un qui décide réellement.

La gouvernance d’accès de Retool est vraiment de premier ordre, et pour un large ensemble d’applis le test du grep ne mord jamais : un outil interne opéré par du personnel de confiance, derrière SSO, maintenu par les mêmes ingénieurs qui l’ont écrit, où « les support leads peuvent rembourser jusqu’à 10 000 $ » est appliqué à trois endroits qui se trouvent concorder et changent rarement. Pour cela — et pour la liberté de plonger dans du SQL et du JavaScript arbitraire dès qu’un besoin est tordu — Retool est excellent, et nous n’allons pas battre « câbler un outil en un après-midi ».

Et le modèle de métadonnées déclarées a un coût réel dans l’autre sens : vous échangez de la flexibilité brute contre de la lisibilité. Vous ne pouvez pas simplement coller du JavaScript arbitraire dans une propriété quand le modèle n’a pas de place pour ça ; exprimer une logique vraiment inhabituelle sous forme de règles déclarées est plus contraint que {{ }} n’importe où. Pour un outil jetable, cette contrainte est du pur surcoût. Le modèle ne s’amortit que lorsque « qui peut faire quoi » est quelque chose dont on vous demandera la preuve — par un auditeur, un régulateur ou le prochain responsable — et lorsque c’est une IA, et non l’auteur d’origine, qui fait les changements.

C’est ça, la ligne. En dessous, Retool gagne au mérite. Au-dessus, le test du grep est ce que vous échouez, six mois plus tard, devant quelqu’un muni d’un porte-bloc.

La position d’ObjectStack

ObjectStack conserve ce que Retool réussit — un contrôle d’accès solide, l’auto-hébergement, votre propre infrastructure — et fait descendre l’autorité dans cette même couche gouvernée. La logique de l’appli est des métadonnées ouvertes et lisibles : une action comme issue_refund porte son propre who_can_run, sa propre barrière d’approbation, sa propre exigence d’audit, déclarés une fois et appliqués par le runtime sur chaque chemin. Un changement d’IA est un diff par rapport à cette autorité déclarée — « ce changement permet à SupportLead de rembourser jusqu’à 25 000 $ » est une ligne qu’un non-ingénieur peut lire et approuver avant la mise en production — pas une expression Hidden que vous découvrez plus tard en faisant un grep.

Nous n’allons pas surpasser Retool sur « plonger dans le JavaScript et livrer un outil avant midi ». La revendication est plus étroite et ne compte qu’au-dessus de la ligne : quand c’est l’IA qui écrit votre logiciel interne, qui-peut-faire-quoi devrait être un fait que vous pouvez lire en un seul endroit et relire comme un diff — pas une propriété émergente de trois expressions qui doivent concorder, et concordent généralement, jusqu’au trimestre où ce n’est plus le cas.