Où est hébergée votre application : trouver le dépôt, l’hébergement, la base de données et le domaine

Ce que signifie vraiment « où vit votre application »

Quand quelqu’un demande où est hébergée votre app, il ne pose rarement une seule question. Il essaie de retracer le chemin depuis le clic d’un utilisateur jusqu’aux systèmes qui font fonctionner votre app.

La plupart des apps ont quatre « maisons » séparées. Les confondre fait perdre des heures :

• Code (dépôt) : où le code source vit et est édité (GitHub, GitLab, Bitbucket, ou dans un outil comme Replit).
• Hébergement (runtime) : où l’app live tourne quand les utilisateurs la visitent (Vercel, Netlify, Render, Fly.io, AWS, un VPS, etc.).
• Base de données : où résident les données (utilisateurs, commandes, contenu) comme Postgres, MySQL, MongoDB, ou un produit de base de données hébergé.
• Domaine et DNS : les réglages qui relient votre nom de domaine à l’hébergement et aux autres services (enregistrements email, vérification, etc.).

Les personnes qui aident demandent d’abord ces détails parce que beaucoup de bugs sont en réalité des problèmes « mauvais emplacement ». Une erreur de connexion peut venir du code, ou d’une variable d’environnement manquante dans les réglages d’hébergement. « Les données ne se sauvegardent pas » peut être un bug de code, ou l’app qui pointe vers la mauvaise base.

Vous pouvez partager beaucoup d’informations en toute sécurité, et ça accélère le processus. Il est généralement sûr de partager les noms de fournisseurs, des captures d’écran du tableau de bord (avec les secrets cachés), les messages d’erreur et les noms de services. Gardez privés tout ce qui donne accès : mots de passe, clés privées, jetons API, chaînes de connexion à la base de données et valeurs complètes des variables d’environnement.

Connaître ces emplacements transforme le dépannage du devin en vérification. FixMyMess voit souvent des prototypes générés par IA où le dépôt existe, mais l’app déployée tourne sur une branche différente, ou des secrets ont été exposés. Une fois le dépôt, le déploiement et la base de données identifiés, les corrections deviennent plus simples et plus rapides.

Une note simple pour capturer l’essentiel

Si vous pouvez nommer les quatre emplacements ci‑dessous, le support sera beaucoup plus rapide car il n’y aura pas d’incertitude sur quoi vérifier en premier.

Copiez et remplissez ceci :

• Repo : fournisseur + nom du dépôt + qui peut donner l’accès
• Hébergement : fournisseur + nom du projet/app + méthode de déploiement (auto depuis git, manuel)
• Base de données : fournisseur + nom de la base + où sont stockées les informations d’accès
• Domaine/DNS : registrar/fournisseur DNS + domaine + qui peut modifier les enregistrements
• Dernier état connu : quand ça marchait pour la dernière fois et ce qui a changé

Si un prototype construit par une IA casse après « un petit tweak », cette note empêche l’erreur classique de corriger le mauvais environnement.

Étape par étape : trouver votre dépôt de code

Si vous ne savez pas encore où est hébergée votre app, commencez par le dépôt quand même. Le dépôt est le meilleur endroit pour voir ce que vous avez réellement, ce qui a changé en dernier, et ce que quelqu’un peut raisonnablement réparer.

Retournez dans le builder IA ou l’outil que vous avez utilisé. Beaucoup d’outils (Lovable, Bolt, v0, Cursor, Replit) ont un réglage comme GitHub, Repository, Export ou Sync qui montre où le code a été poussé. Si vous voyez un compte connecté, notez l’organisation ou le nom d’utilisateur.

Si vous ne vous souvenez pas où le code est allé :

• Ouvrez l’outil avec lequel vous avez construit et cherchez une connexion Git/Repository ou l’historique d’export.
• Cherchez dans vos emails des invitations au repo et des notifications comme « deployment succeeded », « build failed », ou des notifications GitHub.
• Vérifiez tout compte GitHub, GitLab ou Bitbucket que vous avez utilisé et regardez sous Organizations et Repositories.

Une fois le dépôt trouvé, notez ce que les gens demanderont :

• Propriétaire du dépôt (personne ou organisation)
• Nom du dépôt
• Qui a accès (et qui peut donner l’accès)
• Branche par défaut et date du dernier commit

Contrôle rapide : si le dernier commit date de plusieurs mois mais que votre app a changé récemment, vous regardez peut‑être le mauvais dépôt, ou l’outil n’a jamais poussé le dernier code.

Étape par étape : identifier l’hébergement et les déploiements

Quand quelqu’un demande « où est hébergée votre app », il veut en général deux choses : où le site live tourne, et comment le nouveau code y est poussé.

Commencez par l’endroit où vous avez construit l’app. Beaucoup de builders IA et templates ont une page Deploy qui montre un compte fournisseur connecté (par exemple Vercel ou Netlify). Si c’est « connecté à GitHub », les déploiements sont souvent automatiques depuis un repo.

Si vous ne savez pas quel hébergeur c’est, vérifiez votre boîte mail et vos factures pour des noms comme Vercel, Netlify, Render, Fly.io, Railway, ou des fournisseurs cloud (AWS, GCP, Azure). Si vous en trouvez plusieurs, notez lequel sert le site public vs les jobs en arrière‑plan ou la base de données.

Dans le tableau de bord d’hébergement du bon projet, notez :

• Nom du projet/app tel qu’affiché
• Noms des environnements (production, preview, staging) et quelle URL est la production
• Dernier déploiement réussi (et quel commit/version)
• Où se trouvent les logs de build et d’exécution

Puis confirmez comment les déploiements se font. Cherchez des réglages comme « deploy on push » ou « connecté à la branche main ». Si c’est manuel, notez qui peut déployer et ce qu’il faut cliquer.

Exemple concret : votre page d’accueil se met à jour quand vous mergez sur main, mais l’API reste cassée. Cela signifie souvent que le frontend est sur Vercel, tandis que le backend tourne ailleurs (Render, Fly.io, ou un projet cloud séparé). Noter les deux cibles fait gagner du temps.

Si vous apportez ces infos à FixMyMess pour un audit de code gratuit, nous pouvons aller directement aux bons logs et à la bonne pipeline plutôt que de passer du temps à localiser où les choses tournent.

Étape par étape : localiser la base de données derrière votre app

Si vous pouvez nommer le fournisseur de la base et le projet exact, le débogage est beaucoup plus rapide. Beaucoup de problèmes « mon app est cassée » sont en réalité « l’app n’atteint pas la base » ou « elle pointe vers la mauvaise base ».

1) Commencez par les bases gérées courantes

Pour les outils IA et les templates, la base est souvent un service géré. Cherchez Supabase, Neon, PlanetScale, Firebase, MongoDB Atlas, ou AWS RDS dans vos listes d’outils, factures ou emails. Si vous avez un tableau de bord d’hébergement, vérifiez aussi une section « ressources connectées ».

2) Vérifiez les réglages d’hébergement pour les variables d’environnement liées à la base

Dans les paramètres de votre fournisseur d’hébergement, trouvez Variables d’environnement ou Secrets. Vous n’essayez pas de copier la valeur secrète, mais d’identifier le fournisseur et la base cible.

Noms de variables courants :

• DATABASE_URL ou DB_URL
• POSTGRES_URL ou PGHOST
• MONGO_URL ou MONGODB_URI
• SUPABASE_URL (souvent accompagnée de clés)
• FIREBASE_PROJECT_ID

D’après le nom de la variable et les parties non secrètes (comme le hostname), vous pouvez généralement deviner le fournisseur.

3) Analysez le dépôt pour des indices sur la base

Dans votre dépôt, recherchez « supabase », « prisma », « mongoose », « firebase », « postgres », « mysql » ou « mongodb ». Vérifiez aussi des fichiers de config comme .env.example, prisma/schema.prisma, firebase.json ou docker-compose.yml. Ils révèlent souvent le type de base même si le secret live est stocké ailleurs.

4) Notez les détails minimaux (sans secrets)

Écrivez :

• Fournisseur
• Nom du projet ou ID du projet
• Région (si indiquée)
• Nom de la base
• Si vous avez des bases séparées dev/prod

Exemple : si votre host a DATABASE_URL et que le hostname contient « neon.tech », vous pouvez dire au support « Neon Postgres, projet X, région Y, prod et dev séparées. » C’est généralement suffisant pour commencer le diagnostic sans exposer d’identifiants.

Étape par étape : cartographier l’auth et les intégrations clés (souvent le blocage)

L’auth est souvent le premier goulot d’étranglement. « Où c’est hébergé ? » ne suffit pas si personne ne sait quel produit d’auth gère l’accès, quels domaines sont autorisés et où les secrets sont configurés.

Commencez par identifier le fournisseur d’auth et où il est configuré. Cherchez dans le dépôt des fichiers liés à l’auth (auth, middleware, providers) et dans les réglages d’hébergement pour des variables d’environnement. Fournisseurs communs : Clerk, Auth0, Supabase Auth, Firebase Auth, ou une route de login custom.

Notez :

• Quel fournisseur vous utilisez (et le nom du projet/app dans ce fournisseur)
• Quelles méthodes de connexion sont activées (email, Google, GitHub, etc.)
• Vos URLs de redirection en production et domaines autorisés
• Où les sessions sont stockées (cookies, JWT ou base)
• Le texte d’erreur exact (ou une capture d’écran avec les secrets masqués)

La plupart des problèmes « ça marche localement, ça casse en live » sont de petites incompatibilités : les URLs de redirection restent en local, la liste des domaines autorisés n’inclut pas le domaine réel, ou les réglages des cookies ne correspondent pas au HTTPS.

Carte des symptômes :

• Boucle de redirection après login : mauvaise URL de redirection ou domaine du cookie
• « Invalid redirect_uri » : les URLs autorisées ne sont pas mises à jour pour la production
• « Unauthorized » seulement en live : variable d’environnement/secret manquant dans l’hébergement
• Login qui fonctionne mais utilisateur systématiquement déconnecté : cookie de session bloqué ou secret JWT incorrect

Exemple : l’auth Google marche sur votre ordinateur, mais le site live affiche « Invalid redirect_uri. » La correction consiste souvent à ajouter l’URL de callback de production dans le tableau de bord d’auth et à mettre à jour les variables d’environnement en production.

Étape par étape : trouver le domaine et les réglages DNS

Le domaine est la porte d’entrée. Si le DNS pointe au mauvais endroit (ou si personne n’a l’accès), des corrections qui devraient prendre quelques minutes peuvent bloquer des jours.

Commencez par le nom de domaine (exemple : yourapp.com). Cherchez dans vos emails « domain renewal », « registrar » ou le nom de domaine lui‑même. La société qui envoie les reçus de renouvellement est souvent le registrar (GoDaddy, Namecheap, Cloudflare, etc.).

Ensuite, confirmez où le DNS est réellement géré. Ce n’est parfois pas le même endroit que le registrar. Dans le tableau de bord du registrar, cherchez DNS, Nameservers ou DNS Management. Si les nameservers pointent vers une autre société (souvent Cloudflare), c’est cette société qui gère les modifications.

Dans la zone DNS, les enregistrements que les gens doivent généralement vérifier sont :

• Enregistrement A : pointe le domaine racine vers une adresse IP
• CNAME : souvent pour pointer www vers un autre hostname
• TXT : utilisé pour vérification de domaine, réglages email et certains providers d’auth

Puis confirmez vers quoi le domaine pointe et si le SSL est actif. Avertissements de navigateur, changements DNS récents ou enregistrements conflictuels sont des signes que le domaine ne correspond pas à la configuration d’hébergement actuelle.

Exemple : un prototype « marche sur le lien de preview » mais pas sur le domaine réel. La correction consiste souvent à mettre à jour un CNAME ou ajouter un enregistrement TXT, mais seulement si vous savez quel fournisseur DNS contrôle la zone.

Avant de demander de l’aide, notez :

• Nom(s) de domaine et si vous utilisez www
• Registrar et gestionnaire DNS (si différent)
• Qui a l’accès pour modifier le DNS
• Enregistrements clés actuels (A, CNAME, TXT) et changements récents

Checklist rapide à rassembler avant de demander de l’aide

La plupart des retards viennent du fait que le code, l’hébergement, la base de données et le domaine sont détenus par des comptes différents, et personne ne sait qui peut approuver l’accès.

Gardez cette note simple pour la coller dans une requête de support. Si vous ne connaissez pas un élément, écrivez « inconnu » plutôt que de deviner.

• Repo (code) : propriétaire et nom du dépôt, branche principale, date/heure du dernier commit visible.
• Hébergement : fournisseur, nom du projet/app, URL de production, heure du dernier déploiement réussi.
• Base de données : fournisseur, nom/ID du projet, séparation prod/dev.
• Domaine et DNS : registrar, où le DNS est géré, et vers quoi le domaine pointe actuellement (IP A ou cible CNAME).
• Accès et propriété : qui peut accorder les permissions aujourd’hui et quels emails possèdent les comptes.

Exemple : la connexion est cassée, mais le dépôt est sur le GitHub d’un prestataire, le site est déployé depuis un autre compte, et le DNS pointe encore vers une ancienne URL de preview. Avec la checklist ci‑dessus, un développeur peut demander le bon accès et trouver la vraie configuration de production en minutes, pas en jours.

Erreurs courantes qui ralentissent le support

Quand vous ne savez pas où est hébergée votre app, les personnes qui aident passent la première heure à trouver les bases au lieu de réparer le problème.

Bloqueurs fréquents :

• Partir du principe que « c’est sur GitHub » alors que la seule chose existante est un zip téléchargé ou une copie dans un builder. Sans vrai dépôt (historique, branches, version principale claire), il est difficile de revoir les changements ou de revenir en arrière en sécurité.
• Confondre les URLs de preview avec le site de production. Un lien de preview peut fonctionner alors que le domaine payant pointe ailleurs.
• Ne pas avoir accès aux bons comptes. Vous avez peut‑être accès au builder IA, mais pas aux tableaux de bord d’hébergement, au registrar ou à la base de données.

Quelques erreurs à éviter pendant la collecte d’informations :

• Ne postez pas de captures d’écran contenant des clés API, mots de passe ou jetons privés. Si quelque chose a été exposé, changez‑les.
• Ne faites pas d’éditions DNS « rapides » sans noter ce qui a changé. La propagation prend du temps et il est facile de perdre la trace de ce qui casse vs ce qui se met à jour.
• Ne renommez pas des projets, ne supprimez pas des environnements, et ne déconnectez pas d’intégrations « pour faire du ménage » avant qu’une personne ait regardé. Cela supprime parfois des indices nécessaires au diagnostic.

Exemple réaliste : rendre un prototype IA fragile corrigeable

Un·e fondateur·rice a une démo qui a l’air bien en capture d’écran. Elle a été générée avec un builder IA, et la landing charge correctement. Mais quand des utilisateurs réels essaient de se connecter, le site live renvoie des erreurs et les renvoie vers la page d’accueil.

Ils se débloquent en répondant à une question de bout en bout : où vit l’app. Pas seulement le site web, mais le code, le déploiement, la base de données et le domaine.

Ils fouillent leur boîte mail, trouvent un dépôt GitHub oublié, puis vérifient l’hébergement et découvrent le projet sur Vercel. Les déploiements échouent parce que des variables d’environnement nécessaires n’avaient jamais été définies dans le tableau de bord d’hébergement.

Une fois les déploiements opérationnels, la connexion échoue encore. Ils localisent la base de données et réalisent qu’il s’agit d’un projet Supabase utilisant un ancien schéma de table issu d’un prototype précédent. Une petite correction de schéma (ou une migration) rétablit le flux d’auth.

Enfin, le domaine pointe encore vers une ancienne cible. Ils mettent à jour le DNS vers le bon hôte et confirment que le SSL est valide, et les navigateurs n’affichent plus d’avertissement.

Ce qui a rendu la correction rapide n’était pas la chance, mais le fait d’avoir ces détails prêts :

• Emplacement du dépôt et accès
• Fournisseur d’hébergement et statut des derniers déploiements
• Noms des variables d’environnement (pas leurs valeurs secrètes)
• Fournisseur et nom du projet de la base de données
• Registrar du domaine et lieu de gestion du DNS

Prochaines étapes : empaquetez l’info et obtenez de l’aide plus vite

Envoyez un message clair qui répond à la question où est hébergée votre app et comment elle se connecte au reste. L’objectif est d’éliminer les suppositions pour que la personne qui vous aide puisse partir des faits.

Gardez votre « inventaire d’app » court mais complet :

• Repo : où le code vit + nom de la branche principale
• Hébergement : fournisseur + nom du projet/app + comment les déploiements se font (manuel ou auto)
• Base de données : fournisseur + nom de la base + où l’app lit les détails de connexion (variables d’environnement)
• Domaine/DNS : registrar + hôte DNS + où ça pointe
• Auth/intégrations : fournisseur d’auth + parties tierces clés (paiements, email, stockage)

L’accès est souvent le goulot d’étranglement, mais partager des mots de passe est risqué. Préférez des invitations par email avec le minimum de permissions nécessaire, et retirez l’accès après le travail.

Si votre app a été générée par des outils comme Lovable, Bolt, v0, Cursor ou Replit, un audit ciblé est souvent la première étape la plus rapide. Les prototypes générés par IA cachent fréquemment des problèmes comme des secrets exposés, des flux d’auth fragiles ou une logique de base de données fragile. FixMyMess (fixmymess.ai) est conçu pour cette situation spécifique : diagnostiquer la base de code et réparer ce qui est nécessaire pour que l’app tourne de manière fiable en production.