Codex apprend aux sites d'équipe à se mettre à jour selon un planning et à s'adapter au visiteur

OpenAI a publié une courte vidéo sur Codex, qui présente deux mécanismes : les tâches planifiées et les plugins utilisateur. Le premier garde à jour les données d'un site d'équipe, le second personnalise la page pour chaque visiteur. Le point d'entrée est unique : demander à Codex. Il s'agit d'une vidéo accompagnée d'une courte description, sans documentation technique ni chiffres. Voici donc ce que l'on sait avec certitude et les questions qui restent ouvertes.

Ce qu'OpenAI a montré

Dans la description, les Sites sont des sites d'équipe que Codex aide à créer et à maintenir. La vidéo insiste sur deux points.

Le premier est la fraîcheur des données. Des scheduled tasks (tâches planifiées) se connectent au site et actualisent automatiquement les données de la page, par exemple le statut d'un projet, une liste de releases ou une synthèse de métriques. Jusqu'ici, cela exigeait en général une reconstruction manuelle ou un bricolage maison à base de cron. Désormais, le planning vit à l'intérieur de Codex.

Le second est la personnalisation. Les utilisateurs du site connectent leurs propres plugins et obtiennent un affichage construit pour eux. On peut en déduire que le site est capable de s'appuyer sur les données des comptes du visiteur, et pas seulement sur la base commune du propriétaire. La description ne donne aucun exemple de scénario concret : il s'agit donc d'une déduction tirée de la formulation, pas d'une fonction confirmée.

Ce que l'on sait, point par point

• Format : une vidéo sur la chaîne d'OpenAI, avec l'invitation à « simplement demander à Codex ».
• Mise à jour des données : tâches planifiées, sans intervention manuelle.
• Personnalisation : plugins que le visiteur connecte lui-même.
• Pilotage : requête en langage naturel à Codex.
• Non communiqué : fréquence d'exécution des tâches, limites, prix, liste des plugins pris en charge, modèle de droits d'accès.

Où cela mène Codex

Jusqu'ici, un agent de code livrait un résultat sous forme de dépôt, et un humain s'occupait du reste. Ici, Codex prend aussi en charge le cycle de vie : il crée le site, le met à jour selon un planning et montre à chacun un contenu différent. C'est déjà le terrain des portails internes et des outils low-code comme Retool ou Notion, avec un agent dans le rôle d'exécutant.

La principale question concerne la sécurité. Un affichage personnalisé signifie que le site accède d'une manière ou d'une autre aux données du visiteur via les plugins. La vidéo ne permet pas de savoir où le code s'exécute, ce que voit le propriétaire du site, ce qui est mis en cache entre les sessions ni comment un accès est révoqué. Pour des outils d'équipe, ces détails comptent plus que l'idée elle-même.

La seconde question est économique. Les tâches planifiées tournent en permanence. Si chaque exécution consomme des tokens ou des limites de Codex, le coût d'entretien d'un site « vivant » peut devenir notable. Pour l'instant, OpenAI ne dit rien à ce sujet.

Comment l'aborder en pratique

Il vaut mieux commencer par un seul site, celui dont les données deviennent obsolètes le plus vite. Ce peut être une page interne avec le statut d'une release ou une synthèse des tâches. Demandez à Codex d'y associer une mise à jour planifiée, puis comparez le résultat avec ce que l'équipe faisait à la main.

Pour tester la personnalisation, privilégiez des plugins en lecture seule et des comptes de test. Vérifiez trois points : ce que voit exactement le visiteur, ce que voit le propriétaire du site et ce qui reste après la déconnexion du plugin. Surveillez aussi la consommation des limites : les tâches planifiées se lancent facilement, mais elles échappent tout aussi facilement au suivi.

On ne pourra tirer de conclusions complètes qu'après la publication de la documentation. Pour l'instant, la vidéo montre une direction : Codex cherche à devenir un environnement où un site n'est pas seulement créé, mais continue de fonctionner et de s'adapter à ses utilisateurs.