Les connexions générées par l’IA qui plantent en production : un guide de dépannage

À quoi ressemblent les bugs de connexion « ça marche en local »

Une connexion peut sembler correcte en production et pourtant être cassée. Le formulaire est soumis, vous voyez une réponse « succès », puis vous vous retrouvez de nouveau sur l’écran de connexion.

Les symptômes courants incluent :

• Une boucle de redirection entre la page de connexion et l’application
• Vous semblez « connecté » pendant une page, puis vous êtes soudainement déconnecté
• Vous obtenez un 401 ou 403 après un rafraîchissement alors que ça fonctionnait un instant auparavant
• OAuth se termine, mais l’application agit comme si vous étiez déconnecté
• Ça marche sur un navigateur ou un appareil, puis échoue sur un autre

La raison est souvent banale : l’auth dépend de petits détails d’environnement qui changent entre le local et la production. Le dev local a tendance à être un seul hôte, pas de proxy, des cookies simples et du HTTP. La production ajoute HTTPS, de vrais domaines, des reverse proxies et parfois un domaine API séparé. Ces différences affectent la manière dont les cookies sont stockés, quels en-têtes le serveur reçoit et où aboutissent les redirections.

Un exemple typique : en local, vous vous connectez et un cookie de session est défini et stocké. En production, le serveur envoie encore le cookie, mais le navigateur refuse de le stocker parce que les flags du cookie ne correspondent pas à la configuration réelle (souvent SameSite et Secure). Le backend pense que vous êtes connecté, mais le navigateur n’envoie jamais ce cookie. De l’extérieur, ça ressemble à des déconnexions aléatoires ou à une redirection infinie.

Ne devinez pas et ne réécrivez pas tout votre système d’auth. Trouvez l’étape exacte où le flux cesse d’être vrai :

• Le serveur a-t-il envoyé un cookie ou un token ?
• Le navigateur l’a-t-il stocké ?
• La requête suivante l’a-t-elle inclus ?
• La redirection a-t-elle atterri sur le domaine correct ?
• L’API a-t-elle accepté la session ou le token ?

La plupart des échecs d’auth en production sont des problèmes de configuration et de comportement des cookies, pas du formulaire de connexion.

Des équipes comme FixMyMess voient cela fréquemment dans des prototypes construits par l’IA : l’interface a l’air finie, mais les règles de production pour les domaines, HTTPS et les sessions n’ont pas été gérées attentivement.

Avant de toucher au code : récoltez un repro propre

Les gains les plus rapides viennent souvent d’un repro propre et reproductible, pas du hasard. Si vous pouvez provoquer le bug à la demande, vous pouvez prouver la correction rapidement.

Notez le scénario exact pour qu’un autre puisse le suivre sans d’innombrables échanges. Indiquez l’appareil (desktop ou mobile), le navigateur et sa version, la page exacte de départ et quel compte utilisateur vous avez utilisé. Si ça échoue seulement en navigation privée, sur les données mobiles ou après qu’un onglet reste ouvert un certain temps, capturez aussi ces détails.

Précisez aussi où ça échoue. Beaucoup de « bugs de connexion » n’échouent pas sur l’écran de connexion. Ils échouent juste après la connexion :

• Vous soumettez le formulaire et revenez à la page de connexion
• OAuth semble réussi, mais le callback ne se termine jamais
• Vous atterrissez dans l’app, mais le premier appel API retourne 401 et vous êtes expulsé
• Ça marche une fois, puis échoue après un rafraîchissement ou après 10 à 30 minutes

Définissez le succès en termes concrets. Choisissez une ou deux vérifications que vous utiliserez à chaque fois, par exemple : un cookie de session existe, un token est stocké, ou votre endpoint « current user » renvoie 200. Sans ça, les équipes « règlent » l’état de l’UI pendant que le serveur considère toujours l’utilisateur comme anonyme.

Ajoutez des indices temporels et d’identité. Capturez une ou deux horodatations lors de la reproduction (à la minute). Si vos logs backend exposent un request ID, un session ID ou un trace ID, enregistrez-les aussi. Ces indices relient souvent un symptôme navigateur à l’erreur serveur exacte.

Un petit template de repro

Rédigez-le comme un mini cas de test :

• Environnement : production, navigateur + version, appareil
• Étapes : chemin clic par clic depuis un état déconnecté
• Attendu : le signal de succès choisi (cookie défini, token stocké, “current user” renvoie 200)
• Réel : ce que vous avez vu (boucle de redirection, page d’erreur, déconnexion soudaine)

Un exemple réaliste

Un scénario courant est « ça marche en local, ça échoue seulement sur le domaine déployé ». Vous vous connectez, voyez une brève redirection, puis vous vous retrouvez sur la page de connexion.

Votre définition de succès pourrait être : « Après la connexion, la requête current-user renvoie 200 et le cookie de session est présent. » Si vous reproduisez le problème en production et que cette requête renvoie 401, vous avez déjà restreint le champ. Ce n’est pas la vérification du mot de passe. C’est la persistance de la session, les paramètres du cookie, le traitement du callback ou un mismatch de proxy/domaine.

Si vous héritez d’un codebase IA désordonné, ce repro propre aide aussi des services comme FixMyMess à diagnostiquer plus vite car il précise si la rupture est au niveau du login, du callback, du rafraîchissement ou du premier appel API authentifié.

Étape 1 : Tracez le flux de connexion dans le navigateur

La façon la plus rapide d’arrêter de deviner est de regarder ce que le navigateur envoie et reçoit. La plupart des bugs d’auth apparaissent clairement dans l’onglet Réseau.

Ouvrez une fenêtre en navigation privée pour partir d’un état sans cookies ni cache. Ouvrez DevTools et gardez le panneau Réseau visible pendant la connexion.

Que regarder dans Réseau

Trouvez la requête qui soumet les identifiants (souvent un endpoint login ou session). Vérifiez le code de statut, mais ne vous arrêtez pas au « 200 ». Une réponse peut être réussie et pourtant ne pas définir une session ou renvoyer un token exploitable.

Suivez ensuite les requêtes suivantes. Si votre flux utilise des redirections (commun avec OAuth), cliquez chaque réponse de redirection et inspectez l’en-tête Location. Un grand nombre d’échecs en production sont dus à une redirection vers le mauvais domaine, le mauvais chemin ou HTTP au lieu de HTTPS.

Une méthode rapide pour parcourir le flux :

• Identifiez la première requête d’auth et notez le code de statut.
• Pour toute réponse de redirection, confirmez que Location pointe là où vous l’attendez.
• Inspectez les en-têtes de réponse pour Set-Cookie.
• Surveillez les avertissements DevTools sur les cookies bloqués.
• Confirmez que l’appel API suivant inclut un en-tête Cookie ou un en-tête Authorization.

Confirmez que le navigateur a accepté la session

Si vous voyez Set-Cookie dans la réponse, le navigateur peut quand même le refuser. Chrome indique souvent la raison dans les détails du cookie ou l’onglet Issues (SameSite, Secure, domaine ou path mismatch sont fréquents).

Enfin, vérifiez le premier appel API authentifié après la « connexion réussie », comme current-user ou profile. Regardez les en-têtes de requête. S’il n’y a pas de Cookie et pas de token Authorization, le navigateur ne transporte pas votre session. C’est un bon moyen de restreindre le problème : ce n’est pas « le backend a oublié qui je suis », c’est « le client n’a pas envoyé la preuve de connexion ».

Un pattern que FixMyMess voit souvent : tout marche en dev local, mais en production le callback OAuth se termine et l’UI montre encore « déconnecté ». Dans l’onglet Réseau, on repère généralement le moment où le cookie a été défini pour un hôte local seulement ou bloqué parce qu’il manquait Secure sur un site HTTPS.

Étape 2 : Corrigez les flags de cookie qui cassent les sessions

Les cookies sont une cause fréquente des échecs d’auth « ça marche en local ». Le dev local est indulgent. La production ne l’est pas.

Commencez par vérifier les cookies immédiatement après une réponse de connexion réussie. Vous cherchez le cookie de session (ou le cookie de refresh) et si celui-ci est réellement stocké puis renvoyé sur la requête suivante.

Les flags qui décident si votre cookie survit

Domain et Path décident où le cookie est envoyé. Si votre frontend et votre API vivent sur des hôtes différents, un cookie trop restreint peut ne jamais être inclus où vous l’attendez. Le Path peut aussi poser problème : un cookie défini pour un chemin auth-only ne sera pas envoyé aux autres routes API.

SameSite est le point crucial pour OAuth et les redirections cross-site. Si le flux implique de quitter votre site et d’y revenir, les paramètres SameSite peuvent faire disparaître le cookie entre les sauts. Dans beaucoup de cas OAuth, vous avez besoin de SameSite=None, et cela impose une règle stricte : il doit aussi être Secure.

Secure indique au navigateur d’envoyer le cookie uniquement via HTTPS. C’est correct pour la production, mais cela peut casser sur des environnements de staging ou autres qui utilisent encore HTTP.

HttpOnly empêche JavaScript de lire le cookie. C’est généralement ce que vous voulez. Une erreur fréquente dans du code généré par l’IA est que le front-end tente de lire le cookie de session depuis le navigateur et suppose que la connexion a échoué quand il n’y arrive pas.

Avant de modifier le code, vérifiez ces pièges courants :

• Le domaine du cookie correspond à l’hôte de production réel (pas de valeurs locales restantes)
• Le path du cookie est assez large (souvent la racine)
• SameSite correspond à votre flux (surtout pour OAuth)
• Secure est activé pour les environnements HTTPS
• Vous n’avez pas de cookies en double portant le même nom mais des domaines/paths différents

Un exemple rapide : un fondateur déploie derrière un reverse proxy, OAuth « réussit », mais l’app revient en état déconnecté. DevTools montre deux cookies portant le même nom de session, chacun avec une portée différente. Le navigateur envoie le mauvais, donc le serveur le rejette. Ça ressemble souvent à une « auth aléatoire » jusqu’à ce que vous inspectiez la portée des cookies.

Étape 3 : Vérifiez HTTPS, domaines et reverse proxies

Si ça marche en local mais échoue en production, le coupable est souvent en dehors de votre logique d’auth : HTTPS, le domaine public et la position de votre app derrière un proxy.

Assurez-vous que l’app connaît le vrai protocole et hôte

Beaucoup de configurations de production placent votre app derrière un load balancer ou un reverse proxy. Le navigateur parle au proxy en HTTPS, mais votre app peut voir la requête entrante comme du HTTP à moins qu’elle ne fasse confiance aux en-têtes forwardés.

Quand cela arrive, les symptômes courants incluent des cookies définis sans Secure, des redirections vers HTTP et des flux OAuth échouant parce que l’app construit le mauvais callback URL.

Vérifications rapides :

• Dans les logs serveur, affichez le protocole et l’hôte que votre app croit avoir reçus.
• Vérifiez que le proxy envoie les en-têtes forwardés (protocol et host sont les plus usuels).
• Assurez-vous que votre app est configurée pour faire confiance au proxy afin d’utiliser ces en-têtes en toute sécurité.

Éliminez les boucles de redirection et les redirections vers le « mauvais endroit »

Une défaillance classique en production : vous vous connectez, atterrissez dans l’app un instant, puis vous êtes renvoyé encore et encore à la page de connexion. Souvent la connexion a réussi, mais la chaîne de redirection bascule entre HTTP et HTTPS ou entre deux hôtes.

Vérifiez l’onglet Réseau pour les cibles exactes des redirections. Recherchez des motifs tels que :

• Boucles HTTP ↔ HTTPS
• Redirections vers un domaine de staging ou ancien
• Redirections vers un port local qui n’existe pas en production

Confirmez aussi que chaque URL liée à l’auth utilise le domaine public. Les fournisseurs OAuth sont stricts : si votre callback enregistré est une URL mais que votre app envoie les utilisateurs ailleurs, cela échouera.

Sous-domaines, portée des cookies et blocages par le navigateur

Si vous utilisez plusieurs sous-domaines (par exemple un pour l’app et un pour l’API), décidez si les cookies doivent être partagés ou isolés. Les cookies partagés requièrent souvent une portée sur le domaine parent ; les cookies isolés doivent l’éviter.

Les fonctionnalités de confidentialité du navigateur comptent également. Si votre connexion dépend de cookies en contexte tiers (flows intégrés, redirections cross-site), certains navigateurs les bloqueront à moins que SameSite et Secure soient corrects.

Si vous voulez un second avis sur les mismatches proxy et domaine, FixMyMess trouve souvent la redirection ou l’en-tête exact qui cause la rupture lors d’un audit de code gratuit.

Étape 4 : Déboguez les callbacks et redirections OAuth

Les échecs OAuth semblent confus parce que le navigateur saute d’un site à l’autre, et l’erreur peut apparaître chez le fournisseur, sur votre route de callback, ou nulle part.

Localisez précisément où ça échoue

Reproduisez la connexion et faites attention à l’endroit où vous atterrissez :

• Si vous atterrissez sur une page d’erreur du provider, le provider rejette votre requête (souvent un mismatch de redirect URI).
• Si vous revenez sur votre site et obtenez une erreur d’app, votre handler de callback ou l’échange de code en token échoue.
• Si vous revenez « avec succès » mais paraissez toujours déconnecté, le callback peut être complété mais la session n’est pas sauvegardée.

Vérifications à fort impact :

• Comparez l’URI de redirection configurée avec l’URL de callback réelle caractère par caractère (schéma, domaine, chemin, slash final).
• Confirmez que les variables d’environnement correctes sont utilisées pour ce déploiement (client ID, client secret, issuer et base URL de l’app).
• Assurez-vous que state (et nonce pour OIDC) est généré, stocké et validé après la redirection.
• Vérifiez que le callback atteint votre route backend et que le code d’autorisation est présent.
• Vérifiez que l’échange du code renvoie des tokens et que vous gérez les erreurs au lieu de les engloutir.

Motifs courants de mismatch

Les mismatches d’URI de redirection sont rarement évidents. Les erreurs typiques incluent HTTP vs HTTPS, un sous-domaine différent, des chemins callback mélangés, ou un slash final présent à un endroit et pas à l’autre.

Les bugs de state et de nonce sont aussi fréquents dans du code généré par l’IA. Si l’app stocke l’état en mémoire, des déploiements serverless ou plusieurs instances peuvent le perdre entre les redirections. Si l’état est stocké dans un cookie, ce cookie peut ne pas survivre au bounce cross-site.

Un exemple réaliste : la connexion Google marche en local, mais en production retourne « Invalid state ». La cause racine est souvent que la configuration de base URL de l’app pointe encore vers le local, donc le cookie d’état est écrit pour le mauvais hôte et ne revient jamais lors du callback.

Si vous avez besoin d’un second avis, FixMyMess commence typiquement par cartographier l’URI de redirection exacte, le stockage du state et la réponse de l’échange de token afin que le point de rupture soit clair rapidement.

Étape 5 : Validez les JWTs et le refresh des tokens

Si la connexion « marche » mais que les utilisateurs se font déconnecter après un rafraîchissement, un nouvel onglet ou 10–30 minutes, traitez cela comme un problème de token jusqu’à preuve du contraire. De petites différences d’heure, de clés et de règles de validation peuvent transformer un token qui semble correct en local en un token rejeté en production.

Commencez par ce que le serveur pense du token

Décodez le token et vérifiez sa date d’expiration. Comparez-la ensuite à l’heure courante du serveur. Quelques minutes de skew d’horloge peuvent rendre un token tout juste émis déjà expiré, ce qui se manifeste par des 401 aléatoires.

Ensuite, confirmez que la configuration de signature et de validation correspond en production :

• Algorithme : le serveur et le client doivent être d’accord sur l’algorithme de signature.
• Secret ou clés : vérifiez que le secret de signature ou la clé publique déployée est celle réellement utilisée par le serveur.
• Règles de validation : vérifiez issuer et audience. Ceux-ci diffèrent souvent entre local et production, surtout si vous avez copié des valeurs d’exemple depuis un snippet généré par l’IA.

Un cas fréquent « marche en local » : le code local saute les vérifications issuer/audience par commodité, mais le middleware de production les applique. Le token est valide, mais le serveur le rejette à cause d’une audience incorrecte.

Prouvez que le refresh marche après un comportement utilisateur réel

Le refresh doit fonctionner après un reload ou un nouvel onglet. Testez une séquence réaliste : connectez-vous, fermez l’onglet, rouvrez le site et faites un appel API. Si l’app stocke le access token uniquement en mémoire, il disparaît au reload et l’utilisateur semble déconnecté.

Faites attention à l’endroit où les tokens sont stockés. Un stockage persistant survive aux reloads mais augmente le risque en cas de XSS. Les cookies peuvent être plus sûrs lorsqu’ils sont configurés correctement, mais les cookies de token peuvent aussi être perdus si leurs flags ou paramètres de domaine sont incorrects.

Si vous héritez de code IA, il est courant de trouver un flux de refresh à moitié terminé (un refresh token est émis mais jamais utilisé, ou le client n’enregistre jamais le token rafraîchi). L’endpoint de login a l’air correct, mais le chemin « après refresh » n’a jamais été testé.

Une vérification rapide : journalisez la raison du rejet du token côté serveur (expired vs signature vs issuer/audience). Sans cela, vous devinez.

Vérifications côté serveur : CORS, CSRF et stockage de sessions

Les indices du navigateur ne racontent qu’une partie de l’histoire. Le serveur peut rejeter des requêtes silencieusement, ou stocker des sessions dans un endroit que votre app ne peut pas lire de manière fiable.

CORS : autorisez l’origine réelle (et les credentials)

Les problèmes CORS ressemblent souvent à « je me suis connecté, mais la requête suivante est anonyme ». En production, vous avez généralement des origines différentes pour le frontend et l’API.

Assurez-vous que votre API autorise explicitement l’origine de production (pas un joker) et qu’elle est configurée pour accepter les credentials si vous utilisez des cookies. Si le frontend envoie des requêtes avec credentials et que l’API ne renvoie pas les bons en-têtes CORS, le navigateur peut ignorer la réponse ou ne pas accepter les cookies.

Checklist serveur rapide :

• Autoriser l’origine de production exacte (schéma + domaine)
• Retourner l’en-tête permettant les credentials quand vous utilisez des cookies
• Gérer les requêtes préflight (OPTIONS) et retourner les en-têtes attendus
• Éviter des middlewares CORS conflictuels
• Confirmer que les en-têtes autorisés incluent ce que vous envoyez (comme Authorization)

CSRF : le POST marche en local, échoue en prod

Si la connexion utilise POST (ou si vous avez logout, refresh ou mises à jour de profil), les règles CSRF peuvent casser uniquement en production. Deux causes courantes : tokens CSRF manquants et règles de cookie plus strictes.

Pour les sessions basées sur cookies, une valeur SameSite stricte peut empêcher l’envoi du cookie sur des POST cross-site. Le serveur rejette alors la requête car le token CSRF semble manquant ou invalide.

Pour déboguer vite, journalisez ces champs pour la requête qui échoue : origine de la requête, cookies reçus, token/header CSRF et la raison de rejet du framework.

Stockage des sessions, load balancing et secrets

Un échec classique uniquement en production : vous vous connectez, obtenez une session, puis chaque requête suivante ressemble à un nouvel utilisateur. Cela signifie souvent que les sessions ne sont pas partagées entre instances.

Si vous exécutez plus d’un processus serveur (ou si votre hébergeur scale automatiquement), vous avez besoin soit de sticky sessions soit d’un magasin de session partagé. Confirmez aussi le nom du cookie de session et tout préfixe de clé sont cohérents entre instances.

Vérifiez les variables d’environnement également. Un secret d’auth manquant, une clé de signature ou une clé de chiffrement de session peuvent provoquer des « déconnexions aléatoires » après déploiement parce que l’app retombe sur une valeur par défaut. Si cette valeur change au redémarrage, les sessions existantes deviennent illisibles.

Si vous héritez d’une app générée par l’IA et que le comportement serveur est incohérent selon les environnements, FixMyMess peut utiliser un audit de code gratuit pour pointer les problèmes CORS, CSRF, stockage de session et secrets avant que vous ne lanciez une réécriture.

Pièges courants dans le code d’auth généré par l’IA

L’auth générée par l’IA marche souvent en dev local parce que tout est simple : un domaine, un port, pas de proxy et généralement du HTTP. En production, HTTPS, de vrais domaines et souvent un reverse proxy s’ajoutent. De petites hypothèses deviennent de grosses pannes et le navigateur vous renvoie une vague boucle de redirection.

Un pattern qui cause beaucoup de douleur est le mélange de styles d’auth sans règle claire. Par exemple, l’app définit un cookie de session après login, mais l’API attend aussi un bearer token. En local vous envoyez peut‑être par hasard les deux et ça « fonctionne ». En production, un chemin vérifie le cookie, l’autre vérifie le token, et vous vous retrouvez à moitié connecté.

Pièges qui reviennent sans cesse

Faites attention à ces signes quand vous passez en revue le code et la config :

• Mismatch d’environnement : des hypothèses locales sur HTTP, domaines et ports filent en production
• Deux sources de vérité : cookies de session et JWT coexistent sans règle claire
• URL codées en dur : des redirect/callbacks sont figés en local, ou les base URLs sont construites de façon incohérente
• Rotation de secrets : un redeploiement change les clés de signature ou les secrets de session, déconnectant les utilisateurs ou cassant le refresh
• Erreurs englouties : un catch renvoie « ok » ou redirige vers la page de login, masquant le vrai 401/403 ou l’erreur de token

Un exemple réaliste : une app générée par l’IA se connecte bien en local. En production, les utilisateurs soumettent le formulaire mais rebondissent sur la page de login. La cause racine est trois petits problèmes simultanés : le cookie manque Secure, le callback OAuth utilise encore des paramètres locaux, et les erreurs de token sont attrapées et transformées en redirections. Le navigateur n’affiche que des redirections, donc on pense que « l’auth est cassée », alors qu’en réalité le cookie a été perdu.

Si vous héritez d’un projet IA (Lovable, Bolt, v0, Cursor, Replit) et que vous voyez ces patterns, FixMyMess commence généralement par identifier une source unique de vérité pour l’auth, puis resserre les secrets et la config d’environnement pour que les connexions survivent au trafic réel et aux redeploys.

Une checklist courte, un exemple concret et les prochaines étapes

Vous pouvez gagner des heures en vérifiant les bases dans le bon ordre. La plupart des bugs d’auth « ça marche en local » ne sont pas mystérieux. Ce sont habituellement des cookies non stockés, des redirections vers le mauvais endroit, ou l’app qui n’envoie pas les credentials sur le premier appel API.

Une checklist rapide à exécuter en 5–10 minutes :

• Après la connexion, voyez-vous un en-tête Set-Cookie (ou une réponse token) dans l’onglet Réseau ?
• Le navigateur stocke-t-il effectivement le cookie avec le domaine, le path et l’expiration attendus, ou est-il rejeté ?
• Sur la requête suivante, le cookie est-il renvoyé (ou un en-tête Authorization est-il présent) sur votre premier appel API authentifié ?
• Si vous utilisez OAuth, l’URL de callback configurée chez le provider correspond-elle exactement à ce que votre app de production utilise ?
• Lors de l’échange de code, le serveur renvoie-t-il 200, ou voyez-vous un 400/401 silencieux dû à un secret incorrect, un redirect wrong, ou un problème de proxy ?

Un pattern réel : OAuth marche en local, échoue sur le domaine de production. En local tout se complète. En production, le provider redirige, mais l’app ne devient jamais « connectée ». Dans l’onglet Réseau vous pouvez souvent le repérer : le callback atteint votre serveur, le serveur tente de définir un cookie de session, mais le cookie est bloqué parce qu’il manque Secure sur HTTPS ou parce que SameSite est trop strict pour une redirection cross-site OAuth. L’UI se charge, appelle immédiatement current-user, cette requête n’a pas de cookie, le serveur renvoie 401 et l’app rebondit vers la page de login.

Si le flux reste flou, supposez que le code est emmêlé, pas vous. Le code d’auth généré par l’IA mélange souvent responsabilités client/serveur, duplique la logique de session ou disperse la config critique à plusieurs endroits. Un audit ciblé est généralement plus rapide que des suppositions.

FixMyMess (fixmymess.ai) peut diagnostiquer et réparer les flux d’auth générés par l’IA, y compris cookies, sessions JWT, callbacks OAuth et préparation au déploiement. Si vous voulez une liste claire des éléments cassés avant d’engager des changements, nous proposons un audit de code gratuit, et beaucoup de correctifs sont livrés en 48–72 heures.