--- title: "Clerk : authentification et OAuth du dev à la production" description: "Ajouter une vraie authentification avec Clerk, câbler Google OAuth et passer d'une instance dev à une instance de production sur votre propre domaine" type: "lesson" locale: "fr" course: "Le stack applicatif moderne - Auth, données et paiements" number: "3.2" canonical: "https://agenticschool.dev/fr/cours/modern-app-stack/clerk-authentication-and-oauth-from-dev-to-production" datePublished: "2026-06-12" dateModified: "2026-06-12" --- # Clerk : authentification et OAuth du dev à la production - Course: Le stack applicatif moderne - Auth, données et paiements - Lesson: 3.2 - Duration: 30 min - Level: fortgeschritten - Status: published - Canonical URL: https://agenticschool.dev/fr/cours/modern-app-stack/clerk-authentication-and-oauth-from-dev-to-production - Locale: fr > Ajouter une vraie authentification avec Clerk, câbler Google OAuth et passer d'une instance dev à une instance de production sur votre propre domaine ## Summary L'authentification est l'une des choses les plus faciles à rendre dangereusement fausses, donc vous ne la bâtissez jamais vous-même - vous utilisez un service dédié. Cette leçon explique ce qu'est vraiment OAuth, pourquoi l'auth maison est un piège, comment ajouter Clerk et comment passer proprement d'une instance de development à une instance de production, y compris le parcours Google OAuth complet : consent screen, credentials et les DNS records de domaine personnalisé que vous ajoutez à la fin. ## What you learn - Ce qu'est OAuth conceptuellement et pourquoi vous ne devez jamais bâtir l'authentification vous-même - Ajouter Clerk et la différence entre une instance de development et une instance de production - Un parcours Google OAuth de production complet : consent screen, credentials et DNS records de domaine personnalisé ## Vue d'ensemble Votre app a maintenant besoin d'utilisateurs : des gens qui s'inscrivent, se connectent et ont leurs propres données. C'est l'authentification, et c'est un endroit où une petite erreur fuit chaque mot de passe client que vous tenez. Le bon coup en 2026 est sans équivoque : ne la bâtissez pas vous-même, utilisez un service. Clerk est ce service pour la plupart des builders auxquels ce cours s'adresse. Cette leçon explique le seul concept que vous devez comprendre (OAuth), amène Clerk dans votre app, puis vous guide à travers la partie que tout le monde trouve délicate - passer des clés de development à une vraie instance de production avec Google login sur votre propre domaine. ## Ce que vous allez apprendre Vous allez apprendre ce qu'est OAuth en mots clairs, pourquoi l'auth maison est un piège dans lequel tombent même les grandes sociétés, comment Clerk s'intègre à votre app, la différence cruciale entre une instance de development et une instance de production, et les étapes exactes pour activer Google OAuth en production, y compris le consent screen Google, les credentials et les DNS records qui le font tourner sur votre domaine. ## Prérequis Une app fonctionnelle du Cours 1 et la carte d'architecture de la leçon précédente, car l'auth vit côté app, pas côté site marketing. Vous avez aussi besoin de la discipline des secrets du Cours 1 : les clés d'auth sont hautement sensibles et ne doivent jamais être committées. La prochaine leçon sur les secrets va plus loin, mais la règle de base (clés dans .env, .env dans .gitignore) doit déjà être un réflexe. ## Le problème Bâtir l'auth soi-même sonne comme un défi de bravoure. C'est en fait un champ de mines. Vous devez hasher et saler les mots de passe correctement, gérer les sessions et les tokens, traiter les réinitialisations de mot de passe, vous défendre contre le credential stuffing et le brute force, tout stocker en sécurité et suivre éternellement les nouvelles techniques d'attaque. Ratez un détail et vous fuitez des données clients, ce qui est une catastrophe juridique et réputationnelle. Pendant ce temps, vos concurrents ont shippé le login avec Clerk en un après-midi et sont passés à la construction de leur vrai produit. Il n'y a aucun prix pour la version maison. C'est un problème résolu, et votre job est d'utiliser la solution, pas de la réinventer. ## Ce qu'OAuth est réellement OAuth est le protocole derrière chaque bouton « Sign in with Google » ou « Sign in with GitHub ». L'idée centrale est la délégation, sans partager votre mot de passe. Quand un utilisateur clique « Sign in with Google », votre app ne voit jamais son mot de passe Google. Au lieu de cela, votre app le renvoie vers Google, Google confirme qui il est et lui demande d'approuver le partage de son e-mail et de son nom avec votre app, et Google renvoie un token qui prouve « oui, c'est vraiment lui ». Votre app fait confiance à la parole de Google. C'est tout le concept : un tiers de confiance se porte garant de l'utilisateur, pour que vous n'ayez jamais à stocker ou vérifier son mot de passe. C'est plus sûr (vous ne tenez pas de mots de passe), plus pratique (un clic, pas de nouveau compte) et c'est ce que les utilisateurs attendent. Clerk gère toute la danse OAuth pour vous - vous activez simplement les providers que vous voulez. - OAuth = laisser un provider de confiance (Google, GitHub, Apple) se porter garant de l'utilisateur, pour que vous ne touchiez jamais son mot de passe. - Votre app reçoit un token qui prouve l'identité, plus des infos de profil de base que l'utilisateur a approuvé de partager. - Plus sûr pour vous (aucun mot de passe stocké), plus pratique pour eux (un clic). - Clerk pilote le flux OAuth ; vous activez un provider et ajoutez ses credentials. ## Ajouter Clerk à votre app Clerk vous donne des composants drop-in pour l'inscription, le login, le profil utilisateur et la gestion de session, plus les pièces backend pour protéger vos routes. Vous installez son paquet, ajoutez vos clés à votre environnement, enveloppez votre app avec son provider et déposez les composants prêts à l'emploi. Les clés viennent en deux saveurs : une publishable key (sûre dans le code frontend, elle identifie seulement votre app) et une secret key (backend uniquement). Les chemins d'import exacts dépendent de votre framework, alors suivez les docs de Clerk pour les lignes précises. ```bash # .env.local - dev keys, never committed (.env* is gitignored) VITE_CLERK_PUBLISHABLE_KEY=pk_test_xxxxxxxxxxxxxxxxxxxx CLERK_SECRET_KEY=sk_test_xxxxxxxxxxxxxxxxxxxx ``` Les clés Clerk vivent dans votre fichier env. Notez les préfixes pk_test / sk_test - ils signifient development. Notez les préfixes test. Une instance de development émet des clés qui commencent par pk_test et sk_test ; une instance de production émet pk_live et sk_live. Ce préfixe est votre vérification d'un coup d'œil de l'environnement auquel appartient une clé, et c'est de loin le plus souvent confondu. Une fois vos clés posées, vous enveloppez votre app avec le provider de Clerk et utilisez ses composants. ```tsx // A protected page: only signed-in users see the content. import { SignedIn, SignedOut, SignInButton, UserButton } from '@clerk/clerk-react' export function AppShell() { return (
) } ``` Les composants Clerk gèrent toute l'UI connecté / déconnecté pour vous. ## Instance de development versus instance de production Clerk sépare votre projet en deux instances totalement indépendantes. L'instance de development est pour construire : elle utilise des clés test, tourne sur un domaine partagé fourni par Clerk et vient avec des réglages assouplis pour que vous puissiez itérer vite. Elle n'est pas destinée à de vrais utilisateurs. L'instance de production est la vraie chose : clés live, votre propre domaine, sécurité plus stricte et l'endroit où de vrais clients se connectent. Les deux ne partagent ni utilisateurs ni réglages - ce sont des mondes séparés. L'erreur des débutants est de traiter l'instance de development comme suffisante et de pointer de vrais utilisateurs dessus, ou de shipper avec des clés pk_test encore dans leur environnement de production. Le flux propre est : tout construire et tester sur l'instance de development, puis créer l'instance de production, la configurer (y compris un domaine personnalisé et OAuth) et basculer vos variables d'environnement déployées vers les clés pk_live et sk_live. - Instance de development : clés pk_test / sk_test, domaine Clerk partagé, réglages assouplis, pour construire seulement. - Instance de production : clés pk_live / sk_live, votre propre domaine, réglages stricts, pour de vrais utilisateurs. - Ce sont des mondes séparés - utilisateurs et configuration ne se transfèrent pas automatiquement. - Passer en live = créer l'instance de production, la configurer, basculer les env vars déployées vers les clés live. ## Parcours Google OAuth de production Sur l'instance de development, Clerk vous laisse activer le Google login avec des credentials dev partagées, pour que vous puissiez tester aussitôt. Pour la production, Google exige que vous utilisiez vos propres credentials Google et un consent screen vérifié, pour que vos utilisateurs voient le nom de votre app (pas celui de Clerk) quand ils se connectent. C'est la partie qui fait trébucher les gens, alors voici l'ordre qui fonctionne. Les libellés exacts des boutons dans la Google Cloud Console bougent avec le temps, alors faites confiance au flux et suivez les docs à jour de Clerk et de Google pour les clics précis. - Créez (ou choisissez) un projet pour votre app dans la Google Cloud Console. - Configurez l'OAuth consent screen : posez le nom de l'app, l'e-mail de support et votre domaine. Ajoutez les scopes e-mail et profil. Publiez-le pour qu'il ne reste pas en mode test. - Créez des credentials OAuth de type « OAuth client ID » pour une application web. Google vous donne un Client ID et un Client Secret. - Ajoutez la redirect URI autorisée que Clerk vous montre dans ses réglages de provider Google - c'est là que Google renvoie l'utilisateur après approbation. - Collez le Google Client ID et le Client Secret dans les réglages de provider Google de Clerk sur votre instance de production et activez-le. - Test : connectez-vous avec Google sur votre domaine de production. Les utilisateurs devraient voir le nom de votre app sur le consent screen Google, pas un générique. Un piège subtil : la redirect URI doit correspondre exactement, y compris https et sans différence de slash final. Si le login échoue avec une erreur redirect_uri_mismatch, cette correspondance exacte est presque toujours la cause. Copiez l'URI mot pour mot depuis Clerk. ## Domaine personnalisé et DNS records Une instance Clerk de production tourne sur votre propre domaine, pour que l'auth ait lieu par exemple à accounts.yoursite.com ou clerk.yoursite.com au lieu d'une URL Clerk générique. Pour que cela fonctionne, vous ajoutez des DNS records que Clerk vous donne chez votre fournisseur de domaine (ou Cloudflare, du Cours 1). Ce sont surtout des CNAME records qui pointent un sous-domaine vers les serveurs de Clerk, pour que Clerk puisse servir et sécuriser ce sous-domaine. Vous les ajoutez, attendez la propagation DNS, et Clerk les vérifie et émet les certificats. Voici la forme de ce que vous ajoutez - vos vraies valeurs viennent du dashboard Clerk. ```text ; DNS records you add at your provider (example shape - copy real values from Clerk) ; Type Name (host) Value (target) CNAME clerk frontend-api.clerk.services CNAME accounts accounts.clerk.services CNAME clkmail mail.xxxxx.clerk.services CNAME clk._domainkey dkim1.xxxxx.clerk.services CNAME clk2._domainkey dkim2.xxxxx.clerk.services ``` Clerk en production utilise des CNAME records sur des sous-domaines. Les records mail/domainkey laissent Clerk envoyer des e-mails de vérification depuis votre domaine. Si vous gérez le DNS via Cloudflare, ajoutez ceux-ci en DNS-only (nuage gris, non proxifié) sauf indication contraire de Clerk - proxifier les sous-domaines d'auth peut casser le handshake TLS. Après avoir enregistré les records, la vérification peut prendre de quelques minutes à quelques heures. Ce n'est pas cassé, le DNS est juste lent, exactement comme vous l'avez appris en connectant un domaine au Cours 1. ## Erreurs fréquentes Les classiques : shipper avec des clés pk_test encore posées en production, si bien que de vrais utilisateurs atterrissent sur votre instance de development ; oublier de publier le consent screen Google, si bien qu'il reste en mode test où seuls les comptes autorisés peuvent se connecter ; un redirect_uri_mismatch dû à une redirect URI qui diffère d'un slash ou de http versus https ; proxifier les DNS records Clerk via Cloudflare et casser les certificats ; et le plus profond de tous, vouloir bâtir l'auth de zéro « pour apprendre » et shipper un trou de sécurité. Utilisez le service, vérifiez vos préfixes de clé, copiez les redirect URI mot pour mot. ## ROI business L'auth est du pur risque baissier quand vous la bâtissez, et du pur levier quand vous l'achetez. Une table de mots de passe fuitée est un cauchemar juridique sous le RGPD et les lois de protection des données américaines, plus une catastrophe de confiance qui peut tuer un jeune produit. Clerk retire toute cette catégorie de risque pour un coût mensuel modéré et vous donne le social login qui augmente mesurablement la conversion à l'inscription, parce que les utilisateurs détestent créer encore un mot de passe. Vous shippez le login en un après-midi au lieu de deux semaines, vous dormez la nuit, et votre funnel d'inscription convertit mieux. Il n'existe aucune version du calcul où l'auth maison gagne pour une fondatrice qui construit avec des agents. ## Checklist Vous êtes prêt à avancer quand tout ceci est vrai dans une vraie app, pas seulement en théorie. - Vous savez expliquer OAuth en une phrase : un provider de confiance se porte garant de l'utilisateur, pour que vous ne teniez jamais son mot de passe. - Clerk est installé, les clés sont dans .env (gitignored), et l'UI connecté / déconnecté fonctionne. - Vous connaissez la différence entre pk_test et pk_live et l'environnement auquel chacun appartient. - Google OAuth fonctionne sur votre domaine de production avec votre propre consent screen et les bons DNS records. ## Ressources Gardez ouverts les docs de Clerk et le guide OAuth de la Google Cloud Console pendant que vous faites le setup de production - les deux changent leur UI exacte avec le temps, et les docs sont toujours à jour. Les pages de fondamentaux sur ce qu'est OAuth et ce qu'est le DNS étayent les deux concepts les plus délicats ici. Ensuite, vous donnez à vos utilisateurs connectés quelque chose à faire : de vraies données avec Convex. ## Votre mission Ajoutez Clerk à une app de test sur l'instance de development et faites fonctionner le login, puis activez le Google login. Si vous possédez un domaine, allez d'un cran plus loin : créez une instance de production, mettez en place le consent screen Google et les credentials, ajoutez les DNS records et confirmez qu'un vrai Google login sur votre domaine fonctionne avec le nom de votre app sur le consent screen. Parcourir le chemin de production une fois retire la peur pour chaque app que vous bâtissez ensuite. ## Prochaine leçon Les utilisateurs peuvent se connecter. La prochaine leçon leur donne des données avec Convex, une base de données réactive et type-safe où votre logique backend et votre UI restent synchronisées automatiquement, et où vous apprenez aussi le pattern soft delete qui vous laisse annuler une erreur d'utilisateur, au lieu de perdre des données pour toujours. ## Transcript L'authentification est l'une des choses les plus faciles à rendre dangereusement fausses, donc vous ne la bâtissez jamais vous-même - vous utilisez un service dédié. Cette leçon explique ce qu'est vraiment OAuth, pourquoi l'auth maison est un piège, comment ajouter Clerk et comment passer proprement d'une instance de development à une instance de production, y compris le parcours Google OAuth complet : consent screen, credentials et les DNS records de domaine personnalisé que vous ajoutez à la fin.