Localhost n’est pas un environnement de production : diagnostic des applications React qui ne fonctionnent pas lors du déploiement

Une application React qui fonctionne parfaitement sur localhost mais qui cesse de fonctionner dès son déploiement est l’une des frustrations les plus courantes dans le développement frontend. Les requêtes cessent de renvoyer des données, le rafraîchissement d’une page affiche une erreur 404, les images disparaissent, la connexion échoue silencieusement, ou encore la plateforme d’hébergement refuse de compiler du code qui fonctionnait correctement sur votre ordinateur portable. Presque aucun de ces problèmes ne provient de React lui-même. Ils découlent du décalage entre l’environnement dans lequel vous développez et celui que vos utilisateurs rencontrent réellement. Ce guide passe en revue les dix causes les plus fréquentes, montre comment chacune se manifeste, et se termine par une méthode de débogage ainsi qu’une liste de contrôle avant déploiement que vous pouvez réutiliser à chaque publication.

Pourquoi le même code se comporte différemment en production

Un frontend React n’est que rarement l’application dans son intégralité. Il communique avec une API, qui à son tour communique avec une base de données, et chaque maillon de cette chaîne dépend de paramètres de configuration : variables d’environnement, noms de domaine, règles réseau, paramètres d’authentification ainsi que ce que la plateforme d’hébergement fait des requêtes reçues. Sur votre machine, vous contrôlez implicitement tout cela : vous savez sur quel port écoute le backend, quel fichier .env est chargé et quels paquets se trouvent dans node_modules. En production, chacune de ces hypothèses est remplacée par quelque chose de explicite, et tout manque de correspondance peut faire en sorte que du code fonctionnel semble défectueux.

Gardez cette perspective à l’esprit en lisant les sections suivantes. La plupart des correctifs consistent en des modifications de configuration, et non en des modifications de code.

1. L’URL de l’API pointe toujours vers localhost

Lorsqu’une application déployée ne affiche aucune donnée, la première chose à vérifier est la destination de ses requêtes. Pendant le développement, il est courant d’exécuter le backend localement et d’y insérer manuellement son adresse dans le frontend :

const API_URL = "http://localhost:8080/api";

Cela fonctionne car votre navigateur et votre backend tournent sur le même ordinateur. Une fois que le frontend est déployé sur un site comme https://my-app.example.com, la même ligne continue d’envoyer des requêtes vers http://localhost:8080/api. Le problème est que localhost est résolu par le navigateur qui exécute le code. Pour un visiteur, cela signifie son propre ordinateur, et non votre machine de développement. Le chemin de la requête devient donc en réalité :

User's Browser
      ↓
localhost:8080
      ↓
User's computer

Sauf si ce visiteur a justement votre backend en cours d’exécution sur le port 8080, toutes les requêtes échouent.

La solution consiste à cesser de coder manuellement l’adresse et à la lire depuis une variable d’environnement. Dans un projet Vite, vous déclarez sa valeur dans un fichier env :

VITE_API_URL=https://your-backend.example.com/api

et vous la lisez dans votre code à l’aide de import.meta.env :

const API_URL = import.meta.env.VITE_API_URL;

Désormais, le mode développement peut pointer vers http://localhost:8080/api tandis que la version de production pointe vers quelque chose comme https://api.example.com/api, sans aucune modification de code entre les deux. Il s’agit d’une petite refonte, mais elle élimine l’un des erreurs de déploiement les plus fréquentes : demander au navigateur d’un tiers de communiquer avec votre ordinateur portable.

Une mesure de protection similaire consiste à générer une erreur audible en cas d’absence de la variable. Si API_URL vaut undefined, les requêtes sont envoyées vers des chemins tels que undefined/users, ce qui rend le diagnostic difficile. Une vérification en une ligne au démarrage, qui enregistre ou lance une erreur en l’absence de la valeur, permet d’économiser du temps par la suite.

2. Les variables d’environnement de production n’ont jamais été configurées

Les variables d’environnement constituent le prochain suspect habituel. Localement, vous disposez probablement d’un fichier .env qui contient tout ce dont l’application a besoin :

VITE_API_URL=http://localhost:8080/api
VITE_APP_NAME=MyApp

Ces valeurs n’existent que sur votre ordinateur. Une plateforme d’hébergement ne lit pas votre fichier .env local (et elle ne le devrait pas, car ce fichier est généralement exclu du contrôle de version). La version destinée à la production doit recevoir ses propres valeurs, configurées dans les paramètres de variables d’environnement du fournisseur :

VITE_API_URL=https://your-backend.example.com/api

Lorsque vous ajoutez ou modifiez une valeur à cet endroit, il est nécessaire de déclencher un déploiement nouveau. Avec Vite, cette étape n’est pas optionnelle : seules les variables préfixées par VITE_ sont accessibles depuis le code client, et Vite les insère dans le bundle au moment de la compilation. Modifier une variable dans le tableau de bord n’a aucun effet sur un bundle déjà compilé avec l’ancienne valeur.

Les variables frontend ne sont pas des secrets

Il y a une leçon de sécurité cachée là-dedans. Mettre une valeur dans .env ne la rend pas privée. Tout ce qui est exposé au client est compilé en JavaScript que chaque visiteur télécharge et peut lire. Les mots de passe de base de données, les clés API privées et autres identifiants côté serveur ne doivent jamais figurer dans des variables VITE_*. Conservez-les côté backend, ou derrière une fonction serveur, et laissez le frontend appeler une interface qui les utilise à sa place.

3. Les règles CORS n’autorisent que votre origine de développement

Les erreurs liées au partage de ressources entre origines différentes sont une autre surprise classique après déploiement. Imaginez un frontend servi depuis :

https://myapp.example.com

et un backend servi depuis :

https://api.example.com

Ces deux sources sont différentes, car une origine correspond à la combinaison du schéma, de l’hôte et du port. Les navigateurs appliquent la politique du même origine ; par conséquent, pour que le frontend puisse lire les réponses de l’API, le backend doit répondre avec des en-têtes CORS autorisant explicitement l’origine du frontend.

Pendant le développement, le backend était probablement configuré pour accepter les requêtes provenant du serveur de développement Vite :

http://localhost:5173

Tout fonctionnait, ce qui incite à penser que le problème CORS a été résolu. Cependant, après déploiement, l’origine du frontend est :

https://myapp.example.com

Pour le navigateur, il s’agit d’une origine complètement nouvelle. Si l’backend ne liste toujours que http://localhost:5173, le frontend déployé est bloqué. Pour un backend Spring Boot, autoriser l’origine de production sur un contrôleur peut se faire comme ceci (le fragment est en Java) :

@CrossOrigin(origins = "https://myapp.example.com")
@RestController
public class UserController {
    // ...
}

annoter chaque contrôleur fonctionne pour de petits services, mais dans une base de code plus importante, une configuration CORS centrale unique est plus facile à maintenir et il est moins probable de l’oublier lors de l’ajout d’extrémités. Quelle que soit la technologie utilisée, la règle reste la même : les origines autorisées doivent correspondre exactement à l’origine réelle du frontend de production, y compris https et tout sous-domaine. Un modèle courant et fonctionnel consiste à lire la liste des origines autorisées depuis la configuration d’environnement de l’backend lui-même, afin que le développement, les tests et la production autorisent chacun le bon frontend.

Il convient de se rappeler que CORS est un mécanisme du navigateur. Une requête qui échoue avec une erreur CORS dans le navigateur peut réussir avec curl ou Postman, c’est pourquoi tester l’API en dehors du navigateur peut donner une impression trompeuse d’absence de problème.

4. Le renouvellement d’une route côté client retourne 404

Ce problème pousse souvent les développeurs à examiner en détail le code de leur routeur, même lorsque celui-ci fonctionne correctement. Supposons que l’application dispose d’une route telle que :

/dashboard

Vous accédez à la page d’accueil, cliquez sur un lien menant au tableau de bord, et celui-ci s’affiche parfaitement. Vous pouvez naviguer sans aucun problème. Puis vous effectuez un renouvellement, et le serveur répond par :

404 Not Found

L’explication réside dans le fonctionnement des applications single-page. Lorsque vous cliquez sur un lien, React Router met à jour l’URL et affiche entièrement le composant correspondant dans le navigateur ; aucune requête vers /dashboard n’atteint jamais le serveur. Lorsque vous mettez à jour la page ou ouvrez directement cette URL, le navigateur demande au serveur hôte /dashboard. Si le serveur ne connaît que des fichiers réels, il cherche une ressource avec cette adresse, ne trouve rien et renvoie un 404.

La solution consiste en une règle de secours sur l’hébergeur : toute demande concernant une route frontend qui ne correspond à aucun fichier réel doit être réécrite ou redirigée vers index.html. Le navigateur charge ensuite l’application, et React Router lit l’URL pour afficher l’écran approprié. La documentation de déploiement de React Router décrit cette exigence, et la plupart des hébergeurs statiques proposent une configuration ou un petit fichier de configuration à cet effet. Ainsi, lorsque le clic fonctionne mais que la mise à jour échoue, laissez vos routes tranquilles et examinez d’abord la configuration de réécriture des SPA de l’hébergeur. Si vous souhaitez vous rappeler comment les routes sont déclarées, consultez les bases de React Router.

5. Chemins d’import avec une casse incorrecte

Certains bugs restent invisibles jusqu’à ce que la compilation soit exécutée sur un système d’exploitation différent. Imaginez un fichier de composant nommé :

Header.jsx

Importé de cette manière :

import Header from "./components/header";

La seule différence réside en une lettre majuscule, facile à négliger lors des revues. Les systèmes de fichiers ne s’accordent pas sur l’importance de ce détail. Les paramètres par défaut sous macOS et Windows sont insensibles à la casse, ce qui permet à l’import de fonctionner et au programme d’exécuter. La plupart des serveurs de build et des conteneurs fonctionnent sous Linux, dont les systèmes de fichiers sont sensibles à la casse ; ainsi, Header.jsx et header.jsx sont deux noms distincts, ce qui provoque une erreur de build indiquant qu’un module n’a pas été trouvé.

La solution consiste simplement à faire en sorte que chaque import corresponde caractère par caractère au fichier sur le disque. Étant donné :

components/Header.jsx

Écrire l’import de la manière suivante :

import Header from "./components/Header";

Apportez la même attention aux noms de dossiers. Un piège supplémentaire à connaître : renommer un fichier uniquement en changeant sa casse peut ne pas être détecté par Git sur un système de fichiers insensible à la casse, de sorte que le répertoire peut conserver l’ancien nom même si votre éditeur affiche le nouveau. Vérifier le nom que Git traite réellement résout rapidement ce mystère.

6. Les images et les ressources statiques disparaissent

Parfois, l’application se charge elle-même mais ses images, polices ou icônes non. Cela signifie généralement que ces ressources sont référencées par des chemins qui fonctionnaient sur le serveur de développement mais qui n’existent pas dans la version finale.

Vite propose deux mécanismes distincts, et il est utile de savoir lequel vous utilisez. Le premier consiste à importer une ressource depuis le code source :

import logo from "./assets/logo.png";

et à utiliser la valeur importée comme source de l’image :

function App() {
    return <img src={logo} alt="Logo" />;
}

Puisque le fichier est traité par le graphe des modules, Vite le traite lors de la compilation, le copie dans le résultat avec un nom de fichier généré et vous fournit l’URL correcte. Vous n’avez jamais à deviner le chemin final.

public, destiné aux fichiers qui doivent être servis tels quels sans traitement :

public/
└── logo.png

Les fichiers qui s’y trouvent sont copiés dans la racine du résultat de compilation, ce qui vous permet de les référencer avec un chemin d’URL absolu :

<img src="/logo.png" alt="Logo" />

Le principe fondamental réside dans la différence entre un chemin sur votre disque et une URL que le navigateur peut récupérer. Votre éditeur sait peut-être exactement où se trouve src/assets/logo.png, mais le navigateur ne comprend que les URLs que le serveur déployé sert réellement. Si l’application est hébergée sous un sous-chemin plutôt que dans la racine du domaine, des chemins absolus tels que /logo.png peuvent également ne pas fonctionner, c’est précisément ce que gère l’option base de Vite.

Lorsqu’un fichier manque, ouvrez l’onglet Network du navigateur et examinez la requête qui a échoué. Vous verrez généralement soit un chemin inexistant dans la version compilée, soit une erreur 404 du serveur, ce qui vous indique quel des deux mécanismes doit être corrigé.

7. Le serveur de développement n’est pas la version de production

Pour exécuter l’application avec :

npm run dev

Il lance un serveur de développement avec le remplacement en temps réel des modules, des avertissements détaillés et une transformation sur demande de vos modules. Ce qui est déployé, c’est plutôt un ensemble de fichiers statiques compilés et optimisés. Pour un projet Vite, on l’obtient en utilisant :

npm run build

et votre hébergeur sert le résultat obtenu. Comme les deux méthodes traitent votre code différemment, il est tout à fait possible qu’une application fonctionne sous :

npm run dev

mais échoue sous :

npm run build

Cet échec est une bonne nouvelle si vous le détectez vous-même, car vous pouvez le corriger avant que quoi que ce soit n’atteigne les utilisateurs. Vite vous permet également de servir localement le résultat compilé en utilisant :

npm run preview

Cela correspond beaucoup plus à ce que les visiteurs recevront qu’avec le serveur de développement. Faites en sorte que la compilation et la prévisualisation localement deviennent une habitude avant chaque déploiement, plutôt que de laisser la plateforme d’hébergement être le premier endroit où s’exécute la version en production. En intégrant npm run build dans le CI, vous obtenez automatiquement la même garantie à chaque demande de fusion.

8. Vos node_modules locaux cachent des dépendances manquantes

node_modules trop volumineux peut faire croire qu’un projet est en meilleure santé qu’il ne l’est réellement. Au fil des semaines de développement, divers paquets s’y accumulent : des éléments que vous avez installés temporairement pour les essayer, des dépendances transitives d’autres paquets, ou des restes d’une branche que vous avez abandonnée. Votre code peut importer l’un d’eux et fonctionner simplement parce qu’il s’y trouve par hasard.

package.json et le fichier de verrouillage décrivent, rien de plus. Ainsi, si votre code contient :

import axios from "axios";

alors Axios doit être déclaré comme une véritable dépendance du projet, par exemple :

{
  "dependencies": {
    "axios": "^1.0.0",
    "react": "^19.0.0",
    "react-router-dom": "^7.0.0"
  }
}

Les numéros de version dans cet extrait sont indicatifs ; utilisez ceux dont votre projet a réellement besoin. L’objectif est qu’un clone frais suivi d’une installation fraîche contienne tout ce qui est nécessaire pour compiler et exécuter l’application. Committez à la fois package.json et le fichier de verrouillage et maintenez-les en synchronisation, afin que chaque installation utilise les mêmes versions.

Pour reproduire localement les conditions de déploiement, supprimez node_modules et installez à nouveau, de préférence avec npm ci, qui installe strictement à partir du fichier lockfile et échoue si ce dernier est en désaccord avec package.json. Si la compilation échoue par la suite, vous avez découvert une dépendance non déclarée avant votre hébergeur.

9. Le frontend fonctionne bien mais le backend échoue

Il est tentant de blâmer React chaque fois que l’écran affiche des erreurs, mais la cause se trouve souvent plus bas dans la chaîne d’exécution. Supposons que le frontend déployé se charge correctement à :

https://myapp.example.com

Vous ouvrez le tableau de bord et il est vide. Dans l’onglet Réseau, vous constatez :

GET https://api.example.com/api/dashboard
500 Internal Server Error

Ce texte en dit long. L’application React a accompli sa tâche et envoyé la requête ; le backend l’a reçue mais a échoué lors de son traitement. Les causes possibles incluent une connexion à la base de données défectueuse, l’absence d’une variable d’environnement du côté serveur, un problème d’authentification, une exception non gérée ou une configuration différente de celle utilisée localement.

Une requête full-stack typique traverse ces différentes couches :

React Frontend
       ↓
REST API
       ↓
Backend
       ↓
Database

Une panne en bas se répercute en haut. Si la base de données est inaccessible, le tableau de bord semble défectueux même si chaque ligne de code frontend est correcte. C’est pourquoi le diagnostic ne doit pas s’arrêter au navigateur. Lorsqu’une appel API échoue, consultez l’onglet Réseau puis les journaux du backend. Si le navigateur affiche un code 500 et que les journaux du serveur indiquent :

Database connection failed

Vous êtes confronté à un problème de backend ou d’infrastructure, et non à une erreur de rendu. Un frontend qui affiche clairement un état d’erreur pour les requêtes échouées, plutôt qu’une page vide, permet aux utilisateurs comme aux développeurs de distinguer ces deux cas.

10. L’authentification fonctionne localement mais échoue après le déploiement

Les flux de connexion sont particulièrement sensibles aux différences d’environnement. Localement, la séquence peut être la suivante :

localhost → Login → Dashboard

En production, elle devient :

Production → Login → Dashboard doesn't load

Divers problèmes antérieurs peuvent provoquer cela seuls. Le frontend peut encore appeler l’URL API incorrecte, les règles CORS du backend ne peuvent pas inclure l’origine de production, ou les tokens ne sont pas correctement configurés pour le nouvel environnement. Cependant, les cookies sont la cause la plus fréquente.

Pourquoi les cookies se comportent-ils différemment en production

Le fait qu’un navigateur stocke et envoie une cookie dépend de ses attributs : Secure, HttpOnly, SameSite, Domain et Path. En environnement local, tout partage souvent le même hôte, donc ces attributs ont rarement d’importance. En production, l’interface utilisateur et l’API peuvent se trouver sur des domaines différents, via HTTPS, et le navigateur commence alors à appliquer ces règles. Par exemple, une cookie marquée SameSite=None n’est acceptée que si elle est également marquée Secure.

Les requêtes inter-domaines qui transmettent des identifiants nécessitent également la coopération des deux parties. Le client doit autoriser l’envoi de ces identifiants, et le serveur doit les permettre explicitement pour cet origine spécifique ; un origine wildcard n’est pas acceptée pour les requêtes nécessitant des identifiants. Si l’une ou l’autre partie ne remplit pas son rôle, la demande de connexion peut sembler réussir tandis que le cookie de session n’arrive jamais lors des appels ultérieurs.

En résumé : un flux de connexion qui fonctionne sur localhost n’a été testé que dans l’environnement le plus simple possible. Testez-le à nouveau avec un HTTPS similaire à celui en production, des domaines, des paramètres de cookies et des règles CORS.

Méthode de débogage étape par étape

Lorsqu’un déploiement échoue, la réaction la moins efficace consiste à modifier des composants au hasard en espérant que cela fonctionne. La démarche efficace consiste à déterminer quel niveau échoue avant de toucher au moindre code.

Commencez par la console

Ouvrez les outils de développement du navigateur (généralement F12) et consultez la console. Des messages tels que Failed to fetch, des violations CORS, des exceptions JavaScript non capturées ainsi que des erreurs 404 pour les scripts ou les ressources indiquent chacun un problème différent.

Consultez l’onglet Réseau

Passez à l’onglet Réseau et rechargez la page. Pour chaque requête, vous pouvez voir l’URL exacte, la méthode HTTP, le code d’état, le corps de la réponse et souvent les en-têtes. Pour les problèmes liés aux API, c’est l’affichage le plus informatif qui soit. Vous pourriez voir :

GET /api/users
Status: 404

ou :

GET /api/users
Status: 401

ou :

GET /api/users
Status: 500

Chaque code d’état permet de restreindre la recherche :

• 404 : la ressource ou le chemin demandé n’existe pas à cette URL.
• 401 : une authentification est requise, ou les identifiants envoyés manquent ou sont invalides.

403 : le serveur a compris qui vous êtes mais refuse d’autoriser l’action.

500 : le serveur a rencontré une erreur interne lors du traitement de la demande.

Vérifiez l’URL que le navigateur a réellement utilisée

Ne vous fiez pas à ce que vous pensez être le comportement du code source ; examinez la demande que le navigateur a vraiment envoyée. Si c’est la version en production qui appelle :

http://localhost:8080/api/users

alors que le backend se trouve en réalité à :

https://api.example.com/api/users

vous avez presque certainement trouvé le problème, qui est bien l’erreur liée à l’URL de l’API mentionnée dans la section 1.

Suivez les erreurs du serveur jusqu’aux journaux du backend

Un 500 indique que la réponse se trouve sur le serveur. Les journaux du backend peuvent révéler une connexion à la base de données échouée, une variable manquante ou une exception que le frontend ne peut pas signaler. C’est cette habitude de passer au niveau suivant lorsque les indices le suggèrent qui permet de déboguer rapidement les déploiements.

Analyse d’une panne réelle

Prenons un application full-stack qui se déploie sans erreur, mais dont le tableau de bord s’affiche vide. La réaction instinctive est de penser qu’il y a un bug dans le composant du tableau de bord :

"Il doit y avoir un problème avec le composant du tableau de bord."

Au lieu d’ouvrir ce composant, ouvrez l’onglet Réseau. C’est là que vous trouverez :

GET https://api.example.com/api/dashboard
Status: 500

Cela exclut déjà le frontend en tant que cause principale : la requête a bien été envoyée. Ensuite, les journaux du backend montrent :

Database connection failed

Avec ces deux éléments de preuve, toute la chaîne devient claire :

React Frontend
       ↓
API request
       ↓
Backend
       ↓
Database connection failed
       ↓
500 response

Le composant du tableau de bord n’a jamais été en cause. Dix minutes passées à examiner les outils du navigateur et les journaux du serveur ont remplacé ce qui aurait pu être des heures de refacturation du code fonctionnel. Savoir lire les erreurs du navigateur, le trafic réseau et les journaux du serveur en même temps est l’une des compétences les plus précieuses dans le travail quotidien sur du logiciel.

Une liste de contrôle avant déploiement

Le moyen le plus fiable de réduire les surprises liées au déploiement est de tracer, avant envoi, chaque étape parcourue par une requête du navigateur vers la base de données. Voici une liste de contrôle pratique :

• Exécuter npm run build localement et s’assurer que cela réussit, puis vérifier avec npm run preview.
• Vérifier que l’URL de l’API en production est bien définie et qu’aucune requête ne pointe vers localhost.

Vérifiez que chaque variable d’environnement requise existe bien sur la plateforme d’hébergement, et qu’aucun secret n’est stocké dans une variable front-end.

Si le front-end et le back-end se trouvent sur des origines différentes, assurez-vous que le back-end autorise bien l’origine exacte du front-end en production.

Pour les applications React Router, ouvrez directement les routes importantes et mettez-les à jour, plutôt que de cliquer uniquement depuis la page d’accueil.

Vérifiez que les images, polices et autres ressources statiques se chargent correctement dans la version déployée.

Pour les applications nécessitant une authentification, testez la connexion, le déconnexion, les routes protégées ainsi que la mise à jour d’une page pour laquelle l’utilisateur est authentifié.

Surveillez les onglets Console et Network après le déploiement, et consultez les journaux du back-end chaque fois qu’une appel API échoue.

Aucune liste de contrôle ne garantit une mise en production sans erreur, mais celle-ci permet d’identifier la plupart des problèmes courants tant qu’il est encore peu coûteux de les résoudre. Pour une vue d’ensemble plus complète de ce qu’une configuration de projet solide devrait inclure dès le premier jour, la base de React prête pour la production couvre l’aspect des outils.

Pourquoi « ça fonctionne localement » prouve si peu de choses

Votre machine représente un environnement contrôlé et tolérant. Vous savez où s’exécute le backend, quelles variables sont définies, ce qui est installé dans node_modules et quelle base de données l’application utilise. En environnement de production, presque tout change : un domaine différent, une adresse API différente, des variables d’environnement différentes, une base de données différente, des règles CORS et de cookies plus strictes, un serveur auquel il faut indiquer comment gérer les routes côté client, et souvent un système d’exploitation différent. Le code peut être entièrement correct tandis que la configuration qui l’entoure est erronée.

C’est pourquoi le déploiement doit être considéré comme un autre environnement à tester, et non comme une étape finale qui a lieu une fois le développement terminé. Les environnements de préparation, les builds CI et les déploiements en vue préliminaire existent tous pour avancer ces tests plus tôt.

Points clés

• Lorsqu’un élément se brise après déploiement, demandez quel niveau présente un problème avant de vous interroger sur ce qui ne va pas avec React.
• Si rien ne charge, examinez les résultats de la compilation et les ressources ; si la page charge mais pas les données, consultez l’onglet Réseau ainsi que l’URL de l’API.
• Un code 500 vous dirige vers les journaux du backend ; une erreur CORS vous indique les origines autorisées par le backend.
• Une route qui fonctionne en cliquant mais renvoie une erreur 404 à la recharge nécessite un mécanisme de fallback pour les applications SPA sur l’hôte, et non des modifications du routeur.
• Des valeurs manquantes signifient généralement que les variables d’environnement de production n’ont jamais été définies, ou que l’application n’a pas été reconstruite après leur définition.
• Les échecs d’authentification impliquent souvent à la fois les URLs de l’API, les problèmes CORS et les attributs des cookies, il faut donc vérifier ces trois éléments.

Une application déployée est un système composé d’une interface utilisateur, d’une API, d’un backend, d’une base de données, de paramètres de configuration, d’un hébergement, d’un réseau et d’un navigateur. Déboguez chaque couche une par une, et les échecs de déploiement cesseront d’être mystérieux.

Rencontrer de tels problèmes n’est pas un signe de faibles compétences en programmation ; c’est ainsi que tout le monde apprend de quoi sont faits les vrais systèmes. L’objectif n’est pas d’éviter à tout prix les erreurs, mais de devenir rapide pour localiser leur véritable source.