ChatGPT dans GovCloud : le compte OpenAI n’a plus la main
La note de blog d’AWS, publiée le 30 octobre, ressemble à un tutoriel d’installation de plus. Elle contient pourtant une phrase qui devrait faire tiquer quiconque suit la stratégie d’OpenAI côté secteur public : « parce que ce montage passe directement par AWS, les règles de workspace ChatGPT et les rôles utilisateurs ne le contrôlent pas. » Une fois l’app ChatGPT installée sur un poste GovCloud, le compte OpenAI ne décide plus de rien. Ce qui décide, c’est un profil AWS nommé, dans l’exemple du guide, codex-il5.
L’application de bureau ChatGPT est désormais disponible sur Amazon Bedrock dans AWS GovCloud (US), avec deux briques. Work pour les tâches multi-étapes avec un résultat prêt à relire. Codex, l’agent de code, est accessible par l’app, par la CLI et par des intégrations Visual Studio Code, JetBrains et Xcode. L’inférence passe par la Responses API sur Amazon Bedrock, endpoint Bedrock Mantle, région us-gov-west-1. IAM et les contrôles réseau GovCloud existants font le tri.
Le plan de contrôle a changé de camp
C’est ça, la vraie histoire. Pas l’arrivée de ChatGPT chez AWS, mais le fait qu’OpenAI accepte de devenir un client de la chaîne d’identifiants d’un cloud séparé, avec des régions à part et des règles à part, pour entrer chez les clients fédéraux américains. On est loin du partenariat d’affichage. On est dans un déploiement où le fournisseur du modèle troque son propre plan de contrôle contre celui de son hébergeur. Une agence qui a déjà un compte GovCloud, une identité IAM validée et un plan de sécurité n’a plus à faire valider un second fournisseur de compte. Elle ajoute un endpoint.
La résidence des données suit la même logique : le traitement reste dans la région Bedrock choisie. Le paiement se fait au token, sans licence par siège, sans engagement par développeur. Et la rétention zéro est supportée : les prompts et les réponses sont traités sans être écrits dans un stockage durable par AWS, ni partagés avec les fournisseurs de modèles. La formulation est celle d’AWS, elle range OpenAI dans la catégorie des tiers dont on protège les données.
Deux fichiers, et pas de bricolage
Le guide insiste sur un point d’ordre : les fichiers de configuration doivent exister avant le premier lancement. Deux fichiers. requirements.toml d’abord, décrit comme un fichier de règles contrôlé par l’administrateur, qui fixe des limites de sécurité que l’utilisateur ne peut pas surcharger : niveaux de permission autorisés, outils, réglages. config.toml ensuite, qui dit à l’app comment se comporter.
Range ça à côté des habitudes de l’app grand public, où l’utilisateur est roi et où tout se règle dans l’interface. Ici, un fichier écrit par un admin dépossède l’utilisateur avant même qu’il ait cliqué. Le tutoriel va plus loin : configuration réseau restreinte à l’endpoint Bedrock approuvé, autres connexions externes et capacités réseau désactivées. De quoi tester et documenter en local, dans une salle, avant qu’une équipe sécurité autorise un déploiement plus large.
Côté authentification, deux voies. Une clé API Bedrock, ou la chaîne d’identifiants AWS SDK, avec le SSO via IAM Identity Center. L’app cherche d’abord AWS_BEARER_TOKEN_BEDROCK dans son environnement, avec priorité sur l’auth par profil, lit sinon ~/.aws/credentials et ~/.aws/config. Interdiction explicite de fourrer clés, jetons de session et autres secrets dans un fichier TOML. Sage.
Détail qui trahit la généalogie du produit : pour la version desktop, la variable d’environnement se range dans ~/.codex/.env sous Linux et macOS, %USERPROFILE%.codex.env sous Windows. L’app s’appelle ChatGPT, le dossier s’appelle encore codex. Personne n’a pris le temps de renommer, et ça dit tout des briques qui composent la chose.
Le guide ne vaut pas autorisation
AWS le dit lui-même, sans détour : utiliser GovCloud et suivre ce tutoriel n’autorise pas le workload. L’organisation reste responsable d’examiner le modèle retenu, les services AWS, la région, l’endpoint, les contrôles sur le poste, les dépôts, les identifiants et les flux de données contre son plan de sécurité et son processus d’autorisation. Autrement dit, on te vend un mode d’emploi pour ta procédure d’homologation, pas une homologation.
C’est la partie que les annonces « IA dans le secteur public » oublient systématiquement : dans l’administration américaine, le produit n’est jamais le dernier obstacle. L’auditeur l’est. Et pour un auditeur, une facture au token sans engagement par développeur se défend plus facilement qu’un abonnement par tête dans un tableur.
Reste la question qui compte, et elle n’a rien de technique. Quand un agent lit ton dépôt, écrit du code et propose des correctifs sur un poste d’agence, qui a le droit de dire non ? Réponse du guide : un fichier TOML posé par un administrateur, avant le lancement, en amont de tout. Plus fort que le prompt de n’importe quel utilisateur. Voilà le vrai changement de régime, et il n’a demandé aucune conférence de presse.
Sources :
Comments are closed