Si le bouton Publish ou Update affiche "Your Cloud Balance is insufficient to publish" ou "Your Cloud Balance is insufficient to update," votre portefeuille Cloud est épuisé.

Pour résoudre ce problème :

1. Accédez à Settings > Cloud & AI pour vérifier votre solde actuel.

2. Sélectionnez Top up now et ajoutez des fonds à votre portefeuille Cloud.

3. Revenez au panneau Publish et réessayez.

Remarque : votre portefeuille Cloud est distinct de vos Crédits d’abonnement. Le portefeuille Cloud finance les services d’hébergement et de déploiement, tandis que les Crédits d’abonnement sont utilisés pour les conversations avec l’agent IA.

1. Vérifiez la vue d’utilisation du stockage et identifiez les plus grands chats, projets et fichiers.
2. Téléchargez ou sauvegardez tout ce dont vous pourriez avoir besoin plus tard.
3. Supprimez uniquement les éléments inutiles. Si la suppression d’un chat propose de retirer les données disque associées, sélectionnez cette option uniquement après avoir confirmé que ces données peuvent être supprimées sans risque.
4. Actualisez la page et confirmez que l’espace de stockage disponible a augmenté.
5. Revenez à Publish et réessayez une fois.

La suppression peut être permanente et peut casser un projet qui référence un fichier supprimé. Si l’utilisation ne diminue pas, contactez Support avec la vue de stockage, le forfait, le lien du projet et l’heure de l’échec de publication.

Attendez la fin de l’analyse de sécurité, puis examinez chaque élément signalé avant de publier.

1. Sélectionnez Resolve All et inspectez le comportement concerné. Corrigez les problèmes impliquant des secrets exposés, l’authentification, les autorisations, les données utilisateur ou un accès externe non sécurisé avant une utilisation en production.
2. Si un secret a pu être exposé, retirez-le du projet et faites-le pivoter auprès du fournisseur concerné avant de publier.
3. Relancez l’analyse et vérifiez le flux concerné.
4. Utilisez Publish Anyway uniquement lorsqu’un relecteur responsable comprend et accepte le risque restant, non critique. Documentez la raison et évitez de contourner un risque non résolu sur un site de production.

Si vous ne pouvez pas déterminer l’impact d’un résultat, ne publiez pas. Contactez Support ou votre responsable sécurité avec le texte du résultat et des preuves assainies.

1. Testez séparément l’URL de production de la plateforme et le domaine personnalisé. Comparez également la page racine avec la page spécifique ou le chemin API qui échoue.
2. Notez le code de statut exact, l’URL complète, l’heure et le fuseau horaire, et indiquez si l’échec est constant ou intermittent.
3. Vérifiez le dernier statut de déploiement et si une modification récente d’une dépendance, d’une variable d’environnement, de la Base de données ou d’un service externe correspond au début de l’échec.
4. Capturez les erreurs pertinentes de la Console et du Réseau.

Si l’échec persiste, contactez Support avec les étapes de reproduction, la version concernée et des diagnostics assainis. Avant d’envoyer un HAR, une sortie de commande ou une capture d’écran, supprimez les cookies, les en-têtes Authorization, les jetons, les paramètres de requête secrets, les données personnelles et les informations de paiement.

Si votre déploiement expire ou si le site en ligne est temporairement indisponible :

1. Vérifiez si le sous-domaine Prod de la plateforme et Preview sont tous deux inaccessibles, ou seulement l’un des deux.

2. Gardez la page d’erreur actuelle affichée — ne cliquez pas plusieurs fois sur Publish.

3. Vérifiez si vous avez récemment modifié des dépendances, des points d’entrée de démarrage ou des connexions à la base de données, car ces changements peuvent affecter le déploiement.

Si le problème persiste, contactez Support et incluez :

- Lien du projet et URL en ligne

- Heure de l’échec et votre fuseau horaire

- Numéro de version et capture d’écran de la page d’erreur

- Si Preview fonctionne normalement

- Si vous avez récemment modifié des dépendances, l’entrée de démarrage ou la connexion à la base de données

Si le panneau Publish affiche "latest" avec le bouton grisé, ou reste bloqué sur "Building" :

1. Ne cliquez pas plusieurs fois sur Publish — cela n’accélérera pas les choses et peut créer des tâches de build en double.

2. Attendez quelques minutes et actualisez la page.

3. Si le statut ne change pas après actualisation, contactez Support.

Incluez les éléments suivants lorsque vous contactez Support :

- Lien du chat

- Capture d’écran complète du panneau Publish (y compris l’URL de la page, le numéro de version et l’état du bouton)

- Heure de l’incident et votre fuseau horaire

- Numéro de version actuellement affiché

- À quelle étape il a commencé à afficher "Building" ou le bouton est devenu grisé

1. Vérifiez si l’image est absente dans Visionneuse d'App, sur le site publié ou aux deux endroits.
2. Sélectionnez Reload Visionneuse d'App une fois. Si le problème n’apparaît que sur le site en ligne, confirmez que la dernière version a bien été publiée ou mise à jour.
3. Indiquez à l’Agent la page, l’image qui devrait apparaître et l’origine de cette image. Demandez-lui de vérifier que le projet actuel utilise toujours le bon nom d’image et le bon emplacement.
4. Si l’image d’origine a été supprimée ou renommée, téléversez ou sélectionnez à nouveau l’image prévue, puis retestez la page.
5. Si l’image utilise Stockage de l'App ou un autre service connecté, confirmez que le service prévu est connecté et que le fichier y existe toujours.

Si l’image ne se charge toujours pas, contactez Atoms Support avec le Chat Link, l’URL de la page concernée, le nom ou la source de l’image, et une capture d’écran. N’incluez pas de liens d’accès privés, mots de passe, clés ou jetons.

Si le package auto-hébergé exporté se télécharge correctement mais ne s’exécute pas :

1. Consultez le README inclus dans le package d’export pour connaître les exigences d’environnement et les étapes de configuration.

2. Vérifiez que votre environnement d’exécution correspond aux exigences (version de l’OS, version de Docker, version de Node.js).

3. Exécutez la commande de démarrage et examinez la sortie complète pour repérer les messages d’erreur.

Si le problème persiste, contactez Support et incluez :

- Version de l’export et heure du téléchargement

- OS en cours d’exécution et version de Docker

- Commande complète exécutée et sortie complète

- Script ou chemin API en échec

- Méthode de déploiement attendue

Important : joignez un exemple de configuration assaini, mais n’incluez PAS de mots de passe, secrets ou jetons.

Visionneuse d'App et le site publié montrent différentes étapes de votre projet. Enregistrer une modification visuelle ne met pas à jour le site en ligne à lui seul.

1. Dans Design, sélectionnez Save et attendez que la tâche actuelle de l’Agent ou le build se termine.
2. Ouvrez Publish. La publication utilise la dernière version du projet ; il n’y a pas de sélecteur de version dans le panneau Publish.
3. Sélectionnez Publish pour la première publication ou Update pour une publication ultérieure. Attendez que le panneau affiche Up to date.
4. Ouvrez le site en ligne dans un nouvel onglet et rechargez-le une fois.
5. Si l’adresse Atoms par défaut affiche la modification mais pas un domaine personnalisé, vérifiez plutôt la connexion du domaine au lieu de republier plusieurs fois la même version.

Si le site en ligne affiche toujours la mauvaise version, contactez Atoms Support avec le Chat Link, l’URL en ligne, la version que vous vouliez publier, l’heure et le fuseau horaire, ainsi que des captures d’écran de Visionneuse d'App et du site en ligne.

1. Contenez le risque immédiat. Si la publication expose des données sensibles ou crée un comportement dangereux, ouvrez App Status et utilisez Pause pour une app Cloud Atoms éligible ou Unpublish pour supprimer l’accès public. S’il n’y a pas de risque actif, évitez de provoquer une interruption inutile.
2. Notez le domaine concerné, l’heure de publication, la version actuelle, la version prévue et l’impact métier.
3. Une fois la tâche actuelle de l’agent arrêtée, ouvrez Versions, choisissez la dernière version connue comme bonne et sélectionnez Restore this version.
4. Vérifiez la version restaurée dans Preview, y compris les flux critiques de connexion, de paiement et de données, puis publiez-la ou mettez-la à jour.

La restauration d’une version de projet peut ne pas annuler les modifications de la base de données de production ou les actions externes. N’écrasez pas et ne supprimez pas les données de production pour imiter un rollback. Contactez immédiatement Support si des données, identifiants, paiements ou modifications destructrices sont concernés.

1. Arrêtez ou attendez la tâche actuelle de l’agent ; une version ne peut pas être restaurée tant qu’un travail conflictuel est actif.
2. Ouvrez Versions, localisez la dernière version connue comme bonne et sélectionnez Restore this version.
3. Examinez le projet restauré dans Preview et testez les flux critiques qui ont changé.
4. Publiez ou mettez à jour uniquement après avoir confirmé que le résultat dans Preview est correct.

La restauration d’une version de projet ne rétablit pas nécessairement les enregistrements de base de données de production, les changements de schéma, les variables d’environnement, les paiements, les e-mails ou d’autres actions externes. Si la publication a modifié des données de production ou si la version cible n’est pas disponible, arrêtez-vous et contactez Support avec les deux numéros de version, le domaine concerné et le résultat souhaité en matière de préservation des données.

Pause et Unpublish sont deux actions différentes :

Pause (projets Cloud Atoms uniquement) :

- L’app devient indisponible pour les visiteurs.

- Les ressources serveur restent allouées et la facturation continue.

- Vous pouvez reprendre l’app à tout moment depuis App Status.

Unpublish (tous les projets) :

- Le site web est complètement hors ligne. Toute personne utilisant l’URL publiée perd l’accès.

- Pour les projets Cloud Atoms, les ressources serveur sont libérées.

- Vous pouvez republier le projet plus tard, mais les visiteurs ne peuvent pas y accéder tant que vous ne l’avez pas fait.

Utilisez Pause pour un retrait temporaire avec redémarrage rapide. Utilisez Unpublish pour retirer complètement le site.

Si votre navigateur affiche "too many redirects" ou si la page continue de se recharger sans afficher de contenu :

1. Essayez le sous-domaine Prod par défaut de la plateforme (pas votre domaine personnalisé) pour déterminer si la boucle de redirection est causée par la configuration du domaine ou par l’application elle-même.
2. Si le sous-domaine Prod par défaut fonctionne, vérifiez les paramètres DNS de votre domaine personnalisé et les règles de redirection chez votre registraire de domaine qui pourraient entrer en conflit avec la plateforme.
3. Videz le cache de votre navigateur ou testez dans une fenêtre de navigation privée pour écarter l’hypothèse de redirections mises en cache.

Si le problème persiste, contactez Support et incluez :

- URL complète montrant la boucle de redirection

- Si le sous-domaine Prod par défaut est accessible

- Nom de domaine et fournisseur DNS

- Capture d’écran complète de l’erreur

Si votre app fonctionne dans Preview mais échoue en production à cause de variables d’environnement manquantes ou vides :

1. Vérifiez si la variable d’environnement a été enregistrée avant ou après la dernière publication. Si elle a été enregistrée après, vous devez republier pour que la modification prenne effet.
2. Vérifiez que la variable est définie pour le bon environnement (Development vs. Production).
3. Vérifiez si le message d’erreur du service en aval donne un indice — par exemple, "unauthorized" signifie souvent qu’une clé API est vide ou incorrecte dans cet environnement.

Si le problème persiste, contactez Support et incluez :

- Lien du projet ou URL en ligne

- Le nom de la clé concernée et l’environnement qui pose problème

- L’erreur complète du service en aval

- Une capture d’écran assainie de la page de configuration

- Si la configuration a été enregistrée avant ou après la publication

Important : fournissez uniquement les noms des clés. N’envoyez PAS de valeurs secrètes, mots de passe ou jetons.

Les résultats peuvent utiliser une formulation similaire tout en pointant vers des emplacements différents. Une formulation similaire ne signifie pas nécessairement que les résultats sont des doublons.

1. Comparez le nom du résultat et l’emplacement affiché pour chaque résultat.
2. Examinez chaque emplacement unique au lieu d’ignorer la formulation répétée.
3. Si plusieurs résultats ont la même cause sous-jacente, corrigez cette cause puis revérifiez chaque emplacement.
4. Relancez l’analyse de sécurité sur la version mise à jour.

Si le même résultat et le même emplacement apparaissent toujours plus d’une fois, contactez Atoms Support avec le Chat Link, l’heure de l’analyse et le fuseau horaire, le nombre de résultats et une capture d’écran expurgée. Supprimez tous les mots de passe, clés, jetons ou autres informations sensibles pouvant apparaître dans un résultat.

Une analyse terminée sans résultat signalé est une vérification utile, mais elle ne peut pas garantir que tous les problèmes de sécurité ou d’exécution ont été détectés. L’analyse vérifie la version de projet sélectionnée ; votre app doit toujours être testée de la façon dont les vrais utilisateurs l’utiliseront.

Avant de publier, testez les parcours importants dans votre app, y compris la connexion, les rôles utilisateur, l’accès aux données privées, les paiements et les services connectés. Utilisez des comptes de test distincts pour différents rôles et confirmez que chaque compte ne peut accéder qu’aux informations et actions qui lui sont destinées.

Si vous découvrez un problème de production pouvant exposer des comptes, des données privées, des paiements ou des identifiants, arrêtez d’utiliser ou restreignez d’abord l’accès à la fonctionnalité concernée. Faites pivoter tout identifiant qui a pu être exposé, puis contactez Atoms Support avec le Chat Link, la version concernée, les étapes pour reproduire le problème, l’heure et le fuseau horaire, ainsi qu’une capture d’écran expurgée. Ne partagez pas l’identifiant exposé lui-même.

Si l’analyse indique qu’une action réservée à l’administrateur peut ne pas être protégée, considérez le résultat comme non résolu tant que vous n’avez pas confirmé que des utilisateurs non autorisés ne peuvent pas l’utiliser. Masquer un bouton d’administration ne suffit pas si l’action peut toujours être demandée d’une autre manière.

1. Ouvrez le résultat et identifiez l’action ou l’emplacement qu’il mentionne.
2. Déterminez quels rôles connectés doivent être autorisés à utiliser cette action.
3. Demandez à l’Agent de vérifier l’autorisation de l’utilisateur lorsque l’action est demandée, et pas seulement lorsque le bouton est affiché.
4. Testez l’action en étant déconnecté, avec un compte de test normal et avec un compte de test administrateur autorisé.
5. Confirmez que les tentatives rejetées ne révèlent aucune donnée privée et n’apportent aucune modification, puis relancez l’analyse de sécurité.

Ne publiez pas la fonctionnalité concernée si un compte non autorisé peut toujours utiliser l’action. Contactez Atoms Support avec le Chat Link, le texte du résultat, la version concernée et une capture d’écran expurgée si vous ne parvenez pas à résoudre le problème.

HTTPS protège les informations pendant leur transit entre un utilisateur et un service. Si l’analyse signale un problème HTTPS, utilisez le résultat exact pour identifier l’adresse, la ressource, le callback ou la configuration de domaine concerné.

1. Ouvrez le résultat et notez l’emplacement exact et l’adresse qu’il signale.
2. Demandez à l’Agent de remplacer cette connexion spécifique par l’adresse sécurisée prise en charge par son fournisseur, ou de corriger la configuration de domaine associée.
3. N’ignorez pas les avertissements de certificat et ne modifiez pas une adresse à l’aveugle si le service externe ne documente pas d’équivalent sécurisé.
4. Retestez le parcours utilisateur concerné et confirmez qu’aucun mot de passe, jeton, détail de paiement ou information privée n’est envoyé via une connexion non sécurisée.
5. Relancez l’analyse de sécurité sur la version mise à jour.

Si le résultat concerne un domaine personnalisé ou un certificat que vous ne pouvez pas corriger, contactez Atoms Support avec le Chat Link, l’URL concernée, le texte du résultat, l’heure et le fuseau horaire, ainsi qu’une capture d’écran expurgée.

Row Level Security, ou RLS, est une fonctionnalité Supabase qui contrôle quelles lignes de base de données chaque utilisateur peut lire ou modifier. Ce résultat n’est pertinent que lorsque le projet utilise Supabase et que l’analyse identifie une table dont les règles d’accès doivent être examinées.

1. Ouvrez le résultat et identifiez la table qu’il mentionne.
2. Notez qui doit pouvoir voir, ajouter, modifier ou supprimer les données de cette table.
3. Demandez à l’Agent de créer les politiques Supabase les moins permissives possibles qui prennent en charge ces parcours utilisateur.
4. Testez en étant déconnecté et avec un compte de test distinct pour chaque rôle. Confirmez que chaque compte ne peut accéder qu’aux lignes et actions prévues.
5. Relancez l’analyse de sécurité après l’application des politiques.

Ne désactivez pas RLS et n’autorisez pas tous les utilisateurs simplement pour faire disparaître l’avertissement. Avant d’effectuer une modification pouvant affecter des données existantes, confirmez le plan et conservez une sauvegarde ou un export sûr lorsque cela est approprié. Ne partagez jamais de clés Supabase ni d’identifiants de base de données dans le Chat ou dans des captures d’écran.