Codex Sites vs applications web sur mesure : quand utiliser chaque option en 2026

La décision Codex Sites vs application web sur mesure est simple : utilisez Codex Sites pour les applications internes de workspace, les prototypes vérifiables et les outils temporaires. Construisez une application web sur mesure quand des utilisateurs externes, des données métier durables, une auth profonde, la conformité, les intégrations ou la propriété du code source déterminent le projet.

OpenAI n'a pas tué les agences web le 2 juin 2026. OpenAI a tué l'excuse selon laquelle une équipe aurait besoin d'un mois pour voir une première version fonctionnelle.

Cela compte si votre équipe a une idée coincée dans un document, un workflow de tableur ou un dashboard que personne n'a le temps de construire. Cet article vous donne la limite de décision, la checklist de risque et le cadre de prix. Il sépare ce que Codex Sites doit porter de ce qui appartient à une application web sur mesure prête pour la production.

• Codex Sites convient surtout aux applications internes de workspace. Pensez aux planificateurs, dashboards, hubs de revue, jeux et outils ponctuels que votre équipe peut utiliser derrière un accès contrôlé.

• Chaque URL de déploiement Sites est en production. La documentation OpenAI indique de sauvegarder d'abord une version si l'équipe veut vérifier avant un déploiement live.

• Les applications web sur mesure gagnent encore quand l'application est le métier. Utilisateurs externes, données privées, permissions profondes, intégrations API directes et propriété long terme sortent le travail de Sites.

• L'erreur d'achat consiste à appeler plateforme un prototype. Nous avons décrit le même mode d'échec dans les MVP vibe-coded qui deviennent de la dette technique.

• webvise construit des applications full-stack à partir de 7 500 € en 4 à 10 semaines quand le travail exige code source, architecture, monitoring et transfert plutôt qu'une application temporaire de workspace.

Ce que Codex Sites livre réellement

OpenAI a annoncé Codex Sites le 2 juin 2026, avec des role plugins et des annotations pour la revue partagée. L'annonce indique que Codex compte plus de 5 millions d'utilisateurs hebdomadaires, avec une utilisation par les non-développeurs en hausse de 3x le mois précédent et au-dessus de 20 pour cent de l'usage.

La promesse produit est utile parce qu'elle nomme le public. Codex n'est plus seulement une surface de code pour développeurs. C'est un outil de workspace pour des personnes qui ont un plan, un tableur, un processus ou une idée produit approximative et veulent quelque chose d'interactif.

La documentation Codex Sites d'OpenAI décrit un workflow hébergé où Codex peut créer, sauvegarder, déployer et inspecter des sites web, applications web et jeux. Les projets Sites peuvent utiliser D1 pour les données relationnelles, R2 pour le stockage de fichiers, l'identité authentifiée du workspace et des modes d'accès configurables.

Le détail important se rate facilement : chaque URL de déploiement Sites est un déploiement de production. Si vous voulez vérifier avant le live, la documentation dit de sauvegarder une version sans la déployer.

La limite de décision est l'audience et la propriété

La première question n'est pas de savoir si Codex peut construire l'interface. Il peut souvent aller assez loin. La première question est de savoir qui dépend du résultat une fois l'URL créée.

Si l'audience est votre équipe interne, que l'accès reste limité au workspace et qu'une erreur retarde seulement une décision, Sites est un bon choix. Si l'audience inclut des clients, partenaires, auditeurs ou utilisateurs payants, la surface porte un autre profil de risque. L'application exige alors architecture, chemins de support, observabilité et contrôle des changements.

La propriété est la deuxième limite. Un outil temporaire de planification peut vivre dans un workspace hébergé. Un produit central doit vivre dans du code source que vous contrôlez, avec une infrastructure que votre équipe ou votre agence peut inspecter, tester et déplacer.

Si votre réponse tombe trois fois dans la colonne de droite, traitez Sites comme un outil de découverte, pas comme le chemin de production. C'est là que le service d'applications full-stack de webvise intervient : Next.js, PostgreSQL, Better Auth, tRPC, Drizzle, déploiement, monitoring et transfert dans une base de code possédée.

Là où Codex Sites gagne

Sites gagne quand le coût de ne pas voir le workflow dépasse le coût d'une première version approximative. Une équipe peut demander un dashboard, une application de planification, une simulation ou un hub de revue et partager le résultat avec une audience contrôlée.

Une vraie histoire du lancement est le changement de qui peut commencer. Le 2026-06-02, OpenAI a présenté Codex pour chaque rôle, pas seulement pour les développeurs. C'est important parce que beaucoup d'applications internes utiles ne commencent jamais comme tickets. Elles commencent comme modèle financier, plan de lancement ou feuille d'opérations désordonnée.

La bonne demande Sites est étroite : transformez ce plan en outil interne fonctionnel que notre équipe peut inspecter aujourd'hui. La mauvaise demande est large : construisez la plateforme dont nos clients dépendront pendant les trois prochaines années.

• Planificateur de lancement interne. Convertissez une checklist de lancement en tableau de statut avec responsables, dates et blocages.

• Sandbox de prévision. Transformez un modèle de tableur en sliders, tableaux et scénarios sauvegardés pour une revue de direction.

• Jeu de formation. Construisez un petit exercice interactif pour un atelier interne sans commander un produit complet.

• Prototype de workflow. Laissez l'équipe opérations cliquer dans le processus avant que quelqu'un débatte des champs dans une spec.

• Dashboard temporaire. Chargez un jeu de données limité dans une surface de revue pour une réunion hebdomadaire.

Ces applications ont de la valeur. Elles sont aussi bornées. Dès qu'elles deviennent le record of truth, la décision change.

Là où les applications web sur mesure gagnent encore

Les applications web sur mesure gagnent quand le logiciel devient une partie du modèle opérationnel. L'application a besoin d'une auth que vous pouvez expliquer, d'un modèle de données que votre équipe possède, d'intégrations qui ne dépendent pas d'un prompt et d'une gestion d'erreurs qui fonctionne quand personne ne regarde.

Chez webvise, la base full-stack commence à 7 500 € et prend généralement 4 à 10 semaines pour les applications de production. Ce budget paie ce qu'une démo par prompt saute : architecture de base de données, contrats API, permissions par rôle, CI/CD, monitoring et chemin de transfert.

webvise.io est la preuve interne du modèle, sans dépendre d'une preuve de projet externe. Le site n'est pas une brochure. C'est un monorepo Next.js 16 avec tRPC, Drizzle, PostgreSQL, Better Auth, AI SDK 6 via Vercel AI Gateway, sept locales, 93 slugs de blog, 651 fichiers JSON localisés, six pages de service, un outil WordPress Health Report et un assistant AI.

La leçon n'est pas que chaque site d'entreprise a besoin d'autant de mécanique. La leçon est que la vitesse de construction assistée par AI fonctionne mieux dans une architecture définie. L'architecture garde le code utile après la première démo.

Pour l'économie plus large, lisez Build vs Buy Software in 2026. Le même crossover s'applique ici : louez ou générez la surface temporaire, construisez le workflow qui compose de la valeur.

La table de décision 2026

La plupart des équipes ont maintenant quatre chemins, pas deux. Le bon choix dépend de l'audience, du risque sur les données, de la durée de vie et de la propriété.

La table penche volontairement contre la surconstruction. Si le travail est temporaire, utilisez Sites. Si le workflow est stable mais générique, utilisez du no-code. Si le produit doit devenir un actif métier possédé, construisez-le correctement.

Ce n'est pas anti-AI. C'est la version pratique de la livraison assistée par AI. Utilisez l'AI pour raccourcir le chemin vers un logiciel fonctionnel, puis utilisez le jugement d'ingénierie pour décider quel logiciel fonctionnel mérite une vraie base de code.

Une checklist de 20 minutes avant de construire

Avant de demander à Codex, à un app builder ou à une agence de commencer, répondez à ces questions par écrit. Les réponses décident le chemin plus vite qu'une autre démo d'outil.

• Audience : l'accès est-il limité aux employés d'un workspace, ou des clients, partenaires ou prestataires l'utiliseront-ils ?

• Données : stocke-t-elle des PII, paiements, contrats, fichiers, analytics privés ou données opérationnelles ?

• Durée de vie : quelqu'un se souciera-t-il encore de cette application dans 90 jours ?

• Échec : que se passe-t-il si l'application est fausse, indisponible ou obsolète pendant un jour ouvré ?

• Intégrations : a-t-elle besoin d'un accès direct à votre CRM, ERP, base de données, processeur de paiement ou API interne ?

• Permissions : y a-t-il plus de deux rôles, ou un utilisateur doit-il voir des enregistrements qu'un autre ne peut pas voir ?

• Propriété : avez-vous besoin du code source dans votre repository, avec tests, docs et chemin de transfert ?

Marquez un point pour chaque oui hors de la première question. Zéro à deux points signifie : essayez d'abord Codex Sites ou du no-code. Trois ou quatre points signifie : prototypez avec Sites, puis scopez le build. Cinq ou plus signifie : l'application est déjà dans le territoire de l'application web sur mesure.

webvise construit les projets de la colonne de droite : applications full-stack possédées avec code source, auth, intégrations, monitoring et chemin de déploiement que votre équipe peut continuer à utiliser. Si vous décidez si Codex Sites suffit ou si le projet a besoin d'un build sur mesure, envoyez-nous les réponses de la checklist et nous vous dirons quel chemin nous prendrions.