Chaque plateforme dit prendre la sécurité au sérieux. Personne ne le dit non plus dans le post-mortem d'une violation de données — c'est là qu'ils décrivent enfin l'architecture au lieu des adjectifs. Passons donc directement à l'architecture. La façon la plus simple d'expliquer l'isolation multi-locataire est de passer en revue les trois manières dont les équipes s'y prennent généralement mal, et ce qui casse quand elles le font.
Erreur numéro un : filtrer par ID de locataire dans le code applicatif
C'est le comportement par défaut parce que c'est la chose évidente à écrire : chaque requête reçoit une clause WHERE user_id = ? , et tant que chaque développeur s'en souvient, chaque requête reste à l'intérieur de ses propres murs. Le désastre apparaît plus tard, quand la base de code compte quatre cents points d'accès au lieu de quatre. Quelqu'un ajoute une requête de reporting qui joint deux tables et oublie le filtre sur la seconde. Quelqu'un d'autre construit un outil d'administration « juste pour usage interne » qui interroge sans aucune limitation par locataire, parce que ça semblait sûr à l'époque. Aucune de ces erreurs ne fait échouer un test, car la requête retourne toujours des lignes valides — simplement celles du mauvais locataire.
Nous ne comptons pas sur le fait que chaque requête se souvienne de demander poliment. La sécurité au niveau des lignes est appliquée au niveau de la base de données, qui refuse elle-même de retourner les lignes d'un autre locataire, quelle que soit la demande du code appelant. Il n'y a pas non plus de contournement privilégié dans le chemin de la requête — la politique s'applique toujours, y compris aux chemins que nous serions tentés de traiter comme fiables.
Erreur numéro deux : traiter le bac à sable comme une optimisation, pas comme une frontière
Les agents ici exécutent du vrai code — c'est tout l'intérêt du produit — et le raccourci tentant est de faire tourner ce code dans un endroit pratique et de le verrouiller « quand on aura le temps ». Dans cette version, le désastre ressemble à une dépendance compromise récupérée pendant un build qui communique avec l'internet ouvert, ou à l'exécution d'un agent d'un locataire qui lit des fichiers appartenant à un espace de travail qu'il n'était jamais censé voir, parce que le système de fichiers était partagé par défaut et restreint par exception.
Les charges de travail des agents s'exécutent plutôt dans des environnements isolés :
- Systèmes de fichiers verrouillés.
- Sortie réseau limitée à une liste blanche plutôt qu'une porte ouverte.
Un agent travaillant sur votre build voit votre espace de travail, point final. Le code non fiable — y compris les builds de votre propre application — se compile dans des conteneurs où l'isolation est structurelle, pas un paramètre que quelqu'un se serait souvenu d'activer.
Erreur numéro trois : donner les identifiants à l'agent
C'est la plus subtile, et celle qui, je pense, surprend le plus d'équipes. Si l'agent doit déployer sur votre hébergeur ou publier sur votre boutique, le chemin le plus court est de mettre le jeton OAuth ou la clé SSH dans son contexte et de le laisser les utiliser. C'est aussi le chemin le plus court vers le désastre : une instruction injectée par une invite malveillante, une action hallucinée, un identifiant qui se retrouve dans un journal de transcription où il ne devrait pas être. L'agent n'a pas besoin d'être malveillant pour que cela tourne mal — il lui suffit d'avoir tort une seule fois, avec de vraies clés en main.
L'agent ne détient donc jamais les clés. Les identifiants connectés sont stockés de manière limitée à votre compte et utilisés uniquement pour l'action pour laquelle vous les avez connectés :
- Comptes de boutique
- Jetons OAuth des réseaux sociaux
- Clés de déploiement
- Comptes de service Google
Quand un agent doit déployer ou téléverser, il demande à la plateforme de le faire ; la plateforme détient l'identifiant et exécute l'action. L'agent ne voit jamais le secret qu'il demande d'utiliser. Et côté analytique, où les propriétés Google sont parfois partagées entre sites, chaque récupération GA4 est filtrée par nom d'hôte afin que votre tableau de bord ne puisse pas accidentellement afficher les chiffres de quelqu'un d'autre, même lorsque la propriété sous-jacente collecte des données pour plusieurs domaines.
Ce qui est réellement vérifié avant toute mise en ligne
Deux règles s'appliquent partout sur cette plateforme, et c'est ici qu'elles comptent le plus :
- Les agents ne peuvent pas dépenser votre argent.
- Les agents ne peuvent pas publier en votre nom.
Ces deux points nécessitent votre clic. Cela signifie que la pire journée que puisse vivre un composant automatisé ne touche toujours pas votre portefeuille ni votre réputation — le rayon d'impact est limité par conception, pas par le bon jugement de l'agent. Tous les détails sur la conservation et la suppression figurent dans la Politique de confidentialité ; les demandes de suppression prennent effet dans un délai de 30 jours.
