Configuration d’un domaine personnalisé pour une application web : étapes claires pour les enregistrements DNS, l’émission SSL, les redirections et un plan de bascule à faible risque pour éviter les interruptions et les problèmes de cookies.
Un domaine personnalisé, ce n’est pas juste une URL plus propre. Dès que vous passez d’une adresse plateforme (par exemple une app hébergée sur Koder.ai sous un sous-domaine de la plateforme) à votre propre domaine, les navigateurs et les réseaux le considèrent comme un site différent. Cela impacte le routage, la sécurité et le comportement des sessions utilisateur.
Une fois la bascule vers un domaine personnalisé effectuée, plusieurs choses changent immédiatement :
www ou sur l’apex, et il vous faut des règles HTTP→HTTPS cohérentes.old-platform.example ne fonctionnera pas automatiquement sur app.yourdomain.com.Les courtes indisponibilités viennent souvent du timing. Le DNS peut commencer à envoyer du trafic vers la nouvelle cible avant que le certificat SSL ne soit prêt, ce qui provoque des avertissements navigateur. Ou l’inverse : le SSL est prêt, mais de nombreux utilisateurs frappent encore l’ancien endroit à cause du cache DNS.
Les redirections peuvent aussi casser les connexions de façon subtile. Une redirection qui change le hostname (apex → www, ou l’inverse) peut faire perdre des cookies s’ils avaient été définis pour l’autre hôte. Les fournisseurs d’auth peuvent échouer si leur URL de callback pointe encore vers l’ancien domaine.
Un cutover à faible risque signifie planifier un chevauchement : garder l’URL ancienne active, mettre le nouveau domaine en parallèle, basculer le trafic à un moment prévu, et rendre le rollback aussi simple que remettre le DNS en place.
Avant de modifier quoi que ce soit, notez précisément quels noms vous voulez que les utilisateurs tapent et lesquels doivent rediriger silencieusement. La plupart des problèmes du type « pourquoi ça ne marche qu’à moitié ? » viennent d’une équipe qui ne s’est pas mise d’accord sur le hostname unique.
Commencez par le choix principal : l’apex (example.com) ou www (www.example.com) comme primaire. Les deux fonctionnent, mais choisissez-en un et traitez l’autre comme une redirection. Cela compte aussi pour les cookies : les sessions sont généralement plus simples quand l’app vit sur un seul hôte cohérent.
Ensuite, décidez quels sous-domaines vous devez avoir maintenant et lesquels peuvent attendre. Un modèle courant est app.example.com pour l’app web et api.example.com pour les API, avec admin.example.com ou assets.example.com ajoutés plus tard. Si vous configurez un domaine perso sur une plateforme comme Koder.ai, ces choix correspondent directement à ce que vous validerez pour le SSL et à ce que vous pointerez dans le DNS.
Beaucoup achètent un domaine chez un registrar, mais le DNS peut être hébergé ailleurs. Confirmez où les enregistrements sont modifiables aujourd’hui, qui a l’accès et si une automatisation gère des changements (IT interne, une agence, ou un fournisseur DNS managé). Si vous ne pouvez pas vous connecter et voir les enregistrements actuels, arrêtez-vous et réglez ça d’abord.
Auditez aussi ce qui utilise déjà le domaine. L’email est le piège classique : vous pouvez casser la réception en supprimant ou en écrasant des enregistrements.
Avant d’aller plus loin, consignez ces décisions par écrit :
www) et la direction de redirectionSi le marketing gère déjà l’email sur example.com, ne touchez pas aux enregistrements mail et ajoutez seulement ce dont l’app a besoin.
La plupart du risque dans un changement de domaine personnalisé ne vient pas de l’app elle-même. Il vient d’un mauvais changement DNS qui envoie le trafic nulle part, casse l’email ou fait échouer la validation SSL.
Un A record pointe un nom vers une adresse IP. En clair : « envoyez les gens sur ce serveur. » C’est courant pour l’apex (example.com) quand votre fournisseur vous donne une IP fixe.
Un CNAME pointe un nom vers un autre nom. En clair : « considérez ce nom comme un alias de cet hostname. » On l’utilise souvent pour www.example.com pointant vers un hostname de plateforme.
De nombreux fournisseurs DNS proposent aussi ALIAS/ANAME à l’apex. Ils se comportent comme un CNAME mais fonctionnent pour example.com. Si votre fournisseur les supporte, c’est souvent plus simple à gérer parce que la cible peut bouger sans que vous ayez à toucher les IPs.
Un modèle mental simple :
Vous ajouterez souvent des TXT pour prouver la propriété du domaine (vérification plateforme) et pour la validation SSL (certains CA valident via un token TXT). TXT sert aussi aux politiques email comme SPF. Supprimer ou remplacer un SPF TXT existant peut casser la livraison d’e-mails.
Le TTL contrôle combien de temps les systèmes gardent en cache votre réponse DNS. Un jour avant la bascule, baissez le TTL des enregistrements que vous comptez changer (souvent 300 à 600 secondes). Une fois stable, remontez-le pour réduire la charge de requêtes.
Avant d’éditer, exportez ou capturez la zone actuelle. Notez chaque enregistrement que vous changerez, sa valeur ancienne, sa nouvelle valeur et le TTL. Si quelque chose tourne mal, le rollback consiste à restaurer les valeurs précédentes.
Ceci est crucial quand votre domaine a déjà des MX, DKIM ou d’autres TXT pour l’email.
Le SSL (le cadenas) chiffre le trafic entre le navigateur et votre app. Les navigateurs modernes et de nombreuses API s’attendent par défaut à HTTPS. Sans HTTPS, vous pouvez avoir des avertissements, des requêtes bloquées, et des fonctionnalités comme les service workers, la géolocalisation ou certains flux de paiement peuvent cesser de fonctionner.
Pour émettre un certificat, l’autorité de certification doit vérifier que vous contrôlez le domaine. Les méthodes courantes sont la validation HTTP et la validation DNS TXT :
La validation DNS est souvent plus simple quand vous utilisez un CDN ou que votre app n’est pas encore joignable sur le nouveau domaine.
L’endroit où le certificat est émis dépend de votre configuration. Certaines équipes émettent des certs directement sur leur stack d’hébergement, d’autres au niveau du CDN, et certaines plateformes qui supportent les domaines personnalisés s’en occupent pour vous (par exemple, Koder.ai peut gérer le certificat lors de la configuration du domaine). L’important est de savoir qui gère le cycle de vie du certificat, y compris les renouvellements.
L’émission d’un certificat n’est pas toujours instantanée. La propagation DNS, les contrôles de validation et les limites de taux peuvent ralentir le processus. Planifiez des nouvelles tentatives et évitez de programmer la bascule à la dernière minute.
Un plan de timing pratique :
Un certificat doit couvrir chaque hostname que les utilisateurs vont frapper. Vérifiez la liste SAN (Subject Alternative Names). Si votre app sera disponible sur example.com et www.example.com, le certificat doit inclure les deux.
Les wildcards (comme *.example.com) peuvent couvrir de nombreux sous-domaines, mais ils ne couvrent pas l’apex (example.com).
Exemple concret : si vous n’émettez un certificat que pour www.example.com, les utilisateurs qui tapent example.com verront encore des avertissements à moins que vous ne redirigiez à un niveau qui a déjà un certificat valide pour example.com.
Les redirections semblent simples, mais c’est souvent là que se manifestent les problèmes : boucles, contenu mixte, et perte de sessions si les utilisateurs rebondissent entre hôtes.
Choisissez un host canonique et tenez-vous-y : soit www.example.com, soit example.com (apex). L’autre point d’entrée doit rediriger vers l’hôte choisi pour que les cookies, sessions et signaux SEO restent cohérents.
Valeurs sûres :
http:// vers https:// pour chaque requêtePour HTTP → HTTPS, évitez les règles qui renvoient les utilisateurs en boucle. La manière la plus simple d’éviter les boucles est de baser la décision sur la requête réelle. Si votre app est derrière un proxy ou un CDN, configurez-le pour respecter les en-têtes forwardés (par exemple un en-tête indiquant que le schéma d’origine était HTTP). Sinon, votre app peut croire que chaque requête est HTTP et continuer à rediriger à l’infini.
Pendant une migration, conservez les anciens chemins vivants. Si vous changez des routes (comme /login vers /sign-in), ajoutez des redirections explicites pour ces chemins. Ne comptez pas sur une redirection globale vers la page d’accueil : cela casse les favoris et les liens partagés.
Retenez l’HSTS au début. Si vous l’activez trop tôt et devez plus tard servir de l’HTTP pour une validation ou un dépannage, les navigateurs peuvent refuser. Attendez que le HTTPS soit stable et que vous ayez confirmé la couverture des sous-domaines.
Pour tester les redirections sans impacter tout le monde, utilisez un hostname de test temporaire, essayez quelques deep links réels (y compris les pages d’auth) et exécutez une requête en ligne de commande qui montre chaque étape de redirection et la destination finale.
Une bascule sûre tient surtout du timing. Vous voulez que votre nouveau domaine soit prêt et testé avant que de vrais utilisateurs n’y soient envoyés, et vous voulez que les changements DNS se propagent vite pour ne pas rester bloqué en cas d’incident.
Abaissez votre TTL DNS (pour les enregistrements que vous changerez) bien à l’avance. Faites-le la veille si possible, puis attendez la durée de l’ancien TTL pour que les caches aient le temps de prendre la nouvelle valeur.
Ensuite, ajoutez le domaine personnalisé dans votre hébergeur/fournisseur et terminez les vérifications demandées. Si vous utilisez une plateforme comme Koder.ai, ajoutez d’abord le domaine là-bas pour que la plateforme puisse confirmer la propriété et préparer le routage.
Émettez le SSL tôt. Les certificats peuvent prendre quelques minutes ou plus selon la validation, et vous ne voulez pas ce délai pendant la bascule.
Avant de rendre le domaine public, faites un test privé : atteignez le nouveau endpoint d’une façon qui ne dépend pas du DNS public (par exemple en ajoutant une entrée hosts sur votre machine) et confirmez que le site charge en HTTPS avec le bon certificat.
Adoptez une approche étagée pour pouvoir stopper rapidement si quelque chose semble anormal :
www) avant de diriger les utilisateurs.Si vous ne pouvez pas faire un véritable canary au niveau DNS, vous pouvez toujours étager en changeant un seul hostname d’abord (par exemple www) et laisser l’apex tel quel jusqu’à ce que vous ayez confiance.
Écrivez exactement ce que vous allez revenir en arrière (quels enregistrements, quelles valeurs), et qui effectuera la remise en place. Le rollback, en général, consiste à remettre le DNS comme avant.
Assurez-vous que l’ancienne configuration est toujours valide (y compris le SSL sur l’ancien domaine) pour que les utilisateurs puissent revenir proprement pendant que vous corrigez le nouveau chemin.
Un changement de domaine n’est pas qu’un changement DNS. Pour beaucoup d’apps, « être connecté » dépend de cookies que les navigateurs lient à un hostname précis. Si vous passez d’un hostname à un autre, le navigateur peut cesser d’envoyer les anciens cookies et votre app aura l’air d’avoir déconnecté tout le monde.
Les réglages de cookie sont souvent la cause :
app.old.com ne sera pas envoyé à app.new.com. Un cookie défini pour .example.com peut fonctionner sur app.example.com et www.example.com./api), votre UI web peut ne pas le voir.Lax convient souvent, mais certains flux SSO ou de paiement peuvent nécessiter None plus Secure.Pour réduire les risques, prévoyez une courte transition où les deux domaines fonctionnent. Gardez l’ancien hostname répondant et redirigez avec précaution, mais permettez aux sessions d’être renouvelées sur le nouveau domaine. Si possible, utilisez un store de session partagé pour qu’un utilisateur frappant l’un ou l’autre hostname soit reconnu.
Si vous utilisez SSO ou OAuth, mettez à jour les paramètres avant la bascule : URLs de callback, origines autorisées et toutes les allowlists de redirect URI. Sinon, les connexions peuvent réussir chez le fournisseur d’identité mais échouer au retour vers votre app.
Testez d’abord les flux qui cassent généralement : inscription (et vérif email), connexion/déconnexion, réinitialisation de mot de passe, retour de paiement, et sessions multi-onglets.
Exemple : si vous redirigez www.example.com vers example.com, assurez-vous que les cookies sont définis pour .example.com (ou utilisez systématiquement un seul hostname). Sinon les utilisateurs rebondiront entre hostnames et perdront leur session.
La plupart des problèmes de domaine ne sont pas des « mystères internet ». Ce sont de petites incohérences entre DNS, certificats et règles de redirection qui n’apparaissent qu’une fois que de vrais utilisateurs arrivent.
Un piège facile est l’apex (example.com). Beaucoup de fournisseurs DNS n’autorisent pas un vrai CNAME à l’apex. Si vous tentez de pointer l’apex vers un CNAME malgré tout, cela peut échouer silencieusement, résoudre de façon incohérente ou ne marcher que sur certains réseaux. Utilisez ce que votre hébergeur DNS supporte (souvent un enregistrement A/AAAA, ou un ALIAS/ANAME).
Une autre cause fréquente d’indisponibilité est de changer le DNS avant que le SSL ne soit prêt sur la nouvelle cible. Les utilisateurs arrivent, l’app charge, puis le navigateur bloque parce que le certificat est absent ou ne couvre qu’une partie des hostnames. En pratique, vous voulez souvent que le certificat couvre example.com et www.example.com, même si vous comptez rediriger l’un vers l’autre.
Erreurs courantes :
www vers apex, puis apex vers www) ou forcer HTTP à un endroit et HTTPS à un autrehttp:// pour des ressources, ce qui provoque des avertissements et des fonctionnalités casséesUn contrôle de bon sens : ouvrez les deux hostnames (www et apex) en HTTPS, connectez-vous, rechargez et confirmez que la barre d’adresse ne repasse jamais en HTTP.
Si vous faites cela sur une plateforme comme Koder.ai, confirmez que les domaines personnalisés sont connectés et que le SSL est émis avant de toucher au DNS de production, et gardez une option de rollback prête pour qu’une mauvaise redirection ou un mauvais enregistrement ne reste pas en place longtemps.
Une bascule calme, c’est surtout du travail de préparation. L’objectif est simple : les utilisateurs doivent continuer à se connecter, les cookies doivent rester fonctionnels, et vous devez pouvoir revenir en arrière rapidement si quelque chose se passe mal.
Faites ces opérations tant que le trafic va encore vers l’ancien domaine. Donnez-vous une journée si possible, pour que les changements DNS aient le temps de se stabiliser.
www, api, etc.) et choisissez votre méthode de validation SSL (DNS ou HTTP).www → apex (ou l’inverse), et un host canonique.Quand vous changez le DNS, traitez la première heure comme un exercice d’incident. Surveillez les parcours réels utilisateurs, pas seulement les tableaux de bord de statut.
Même si Koder.ai (ou une autre plateforme) gère les domaines personnalisés et le SSL pour vous, cette checklist reste pertinente. La plupart des problèmes viennent du DNS et des redirections, pas du code de l’app.
Votre app tourne sur une adresse temporaire de plateforme comme myapp.koder.ai. Elle fonctionne, mais vous voulez que les clients utilisent example.com, avec www.example.com redirigeant vers l’apex, et tout forcé en HTTPS.
Un plan DNS simple limite les risques. Avant de toucher quoi que ce soit, notez l’état fonctionnel actuel (faites une capture si la plateforme le permet, comme le fait Koder.ai) et réduisez le TTL DNS à une valeur courte la veille.
Ajoutez les nouveaux enregistrements tout en laissant l’URL plateforme existante intacte :
example.com : enregistrement A/ALIAS pointant vers la cible d’hébergement fournie par votre plateformewww.example.com : CNAME pointant vers example.com (ou vers la cible de la plateforme, selon le fournisseur)myapp.koder.ai tel quel pour garder un fallback connu et fonctionnelUne fois le DNS en place, demandez le SSL pour les deux hostnames (example.com et www.example.com). Ne basculez pas le trafic tant que le certificat n’est pas émis et actif, sinon les utilisateurs verront des avertissements navigateur.
Calendrier de bascule avec points de contrôle :
example.com en fenêtre privée (page d’accueil, assets statiques, appels API)www → apex)Après la migration, validez le comportement des cookies. Connectez-vous, rafraîchissez et vérifiez que la session reste active sur www et l’apex. Si les sessions sautent, c’est souvent un problème de domaine de cookie ou de SameSite qui suppose encore l’ancien hôte.
Une fois que la bascule fonctionne, le travail n’est pas fini. La plupart des migrations échouent plus tard parce que personne ne remarque une dérive : un certificat proche de l’expiration, un changement DNS fait à la va-vite, ou une modification de redirection qui casse un flux de connexion.
Mettez en place une petite routine de surveillance que vous maintiendrez réellement. Pas besoin d’un outil enterprise pour commencer, mais il vous faut quelques signaux fiables : checks de disponibilité pour les pages clés (accueil, connexion, une page authentifiée), alertes d’expiration de certificat (par exemple à 30 jours puis 7 jours), suivi du taux d’erreur (surveillez les pics 4xx/5xx, pas seulement la disponibilité) et validations régulières des redirections (HTTP → HTTPS et que l’hôte préféré gagne).
Conservez une courte fenêtre de rollback, même si tout semble OK. Pendant 24 à 72 heures, gardez l’ancienne configuration prête (anciennes cibles DNS, ancienne config d’hébergement, anciens certificats) pour pouvoir revenir vite si un problème caché surgit, comme un callback de paiement ou un fournisseur OAuth pointant encore sur l’ancien domaine.
Quand vous êtes confiant, remontez les TTL DNS à des valeurs normales. Un TTL bas est utile pendant un changement, mais il augmente la charge sur les résolveurs et rend les petites erreurs plus impactantes plus tard. Choisissez un TTL habituel adapté à la fréquence prévue de vos changements (beaucoup d’équipes choisissent 1 à 4 heures).
Enfin, documentez l’état final tant que c’est encore frais : quels enregistrements existent (type, nom, valeur, TTL), quels hostnames sont supportés, et les règles exactes de redirection. Indiquez où les certificats sont émis, ce qu’ils couvrent (apex, www, sous-domaines) et qui gère les renouvellements.
Si vous déployez sur une plateforme, c’est utile que les domaines soient traités comme une fonctionnalité de première classe et que le rollback soit simple. Sur Koder.ai, les domaines personnalisés coexistent avec les snapshots et le rollback, ce qui peut rendre les futurs changements de domaine et de redirection moins stressants lorsqu’il faut annuler rapidement.
Par défaut, choisissez un seul hostname canonique et redirigez tout le reste vers lui.
example.com (apex) ou www.example.com comme « réel ».Cela permet de garder les cookies, sessions et favoris cohérents et évite les comportements partiellement fonctionnels.
Abaissez le TTL la veille du basculement planifié, puis attendez que l’ancien TTL ait expiré.
N’abaissez le TTL que sur les enregistrements que vous comptez changer.
Pour beaucoup de configurations d’apps :
www.example.com ou app.example.com lorsque vous pointez vers un hostname fournisseur.Ne basculez pas le trafic utilisateur tant que HTTPS n’est pas valide sur les nouveaux hostname(s).
Ordre pratique :
Cela évite les avertissements navigateur et les requêtes bloquées lors de la bascule.
Les pannes d’email surviennent généralement lorsque l’on supprime ou écrase des enregistrements MX et TXT.
Avant toute modification :
Les boucles de redirection viennent souvent de règles conflictuelles entre votre CDN/proxy et l’application.
Utilisez ces paramètres sûrs :
http:// → https://Si vous êtes derrière un proxy/CDN, assurez-vous que l’application respecte les en-têtes de schéma forwardés ; sinon elle peut croire que chaque requête est en HTTP et rediriger indéfiniment.
Oui, c’est courant si les cookies étaient limités à l’ancien hostname.
Éléments à vérifier :
old-host ne sera pas envoyé à new-hostMettez à jour les paramètres d’identité avant la bascule.
Éléments typiques qui doivent correspondre exactement au nouveau domaine :
Si ces éléments pointent encore vers l’ancien domaine, la connexion peut réussir côté fournisseur mais échouer au retour vers votre app.
Un rollback consiste généralement à restaurer les anciennes valeurs DNS.
Gardez-le simple :
Si votre plateforme propose des snapshots/rollback (Koder.ai le fait), prenez-en un avant la bascule pour pouvoir annuler rapidement aussi la configuration liée.
Testez les parcours utilisateurs réels, pas seulement la page d’accueil.
Testez ceci sur l’hôte canonique et l’hôte redirigé :
Vérifiez aussi que la barre d’adresse reste sur , toujours en , sans avertissement de contenu mixte.
example.comÉvitez de forcer un CNAME à l’apex si votre hébergeur DNS ne supporte pas le style d’alias pour l’apex.
Une mesure de sécurité rapide : exporter ou faire une capture d’écran de la zone DNS actuelle pour pouvoir la restaurer rapidement.
Approche à faible risque : conservez l’ancien hostname opérationnel pendant la transition pour permettre aux utilisateurs de rafraîchir leurs sessions sur le nouveau domaine.