Technique

Ouvrez d'abord la page de statut du build — chaque étape a un bouton Logs qui montre exactement où ça a planté. La plupart des échecs entrent dans trois catégories : un hoquet d'infra ponctuel (cliquez sur Retry), une erreur de code que l'IA peut corriger seule (lancez un chat avec « le build a échoué, l'erreur est : … » et collez la ligne pertinente), ou un problème avec un service connecté (Stripe, GitHub, votre fournisseur de domaine). Si rien ne s'applique, écrivez au support avec l'ID du projet — nous pouvons relancer le pipeline manuellement.

Trois causes courantes. (1) Le DNS n'est pas encore totalement propagé — attendez 5 à 15 minutes et faites un hard refresh. (2) Votre navigateur a mis en cache un ancien asset — ouvrez en navigation privée. (3) La sortie du premier build était syntaxiquement correcte mais logiquement fausse — lancez un chat avec « la page d'accueil est blanche quand je l'ouvre » et l'IA corrige au prochain raffinement. La console du navigateur (F12 → Console) montre généralement l'erreur réelle.

Les builds tournent dans une file partagée. Les plans Free et Starter ont une priorité standard et peuvent attendre quelques minutes aux heures de pointe ; Pro et Business bénéficient d'emplacements prioritaires et n'attendent presque jamais. Si votre build est en file depuis plus de 10 minutes, ce n'est pas normal — rafraîchissez la page (le statut passe par websocket et la connexion tombe parfois), et s'il ne démarre toujours pas, écrivez au support avec l'ID du projet.

Oui. Ouvrez le projet, cliquez sur le menu à trois points et choisissez « Redéployer ». Votre code reste exactement le même — mais les nouvelles variables d'environnement sont prises en compte, les artefacts de build expirés sont reconstruits et les éventuelles améliorations côté plateforme (correctifs de sécurité du runtime, par exemple) sont appliquées. Un redéploiement sans changement coûte 1 crédit et se termine en moins d'une minute.

Sur AWS, dans la région us-east-1 par défaut. Les assets statiques sont servis depuis le réseau edge mondial de CloudFront, vos visiteurs touchent donc un PoP proche quelle que soit la position de l'origine. Le rendu côté serveur tourne sur AWS Lambda, la base de données du projet est sur Amazon RDS Postgres, et les fichiers uploadés résident dans S3. La résidence des données en UE est sur la roadmap mais pas encore disponible — prévenez le support si c'est une exigence stricte.

Oui — le code de votre projet se trouve dans un dépôt GitHub que nous avons créé à votre nom. Ouvrez Paramètres du projet → Dépôt pour voir l'URL et donner les droits d'écriture à votre compte. Cloner, forker ou déplacer vers une autre org GitHub fonctionne comme pour n'importe quel dépôt. Idem pour la base de données (nous exposons une chaîne de connexion Postgres sous Paramètres → Base de données → Export). Vous conservez la propriété du code et des données ; FloopFloop est une couche de déploiement + IA par-dessus.

À partir de Pro : ouvrez le projet, allez dans Paramètres → Domaines, cliquez sur « Ajouter un domaine » et saisissez votre domaine (racine ou sous-domaine). FloopFloop affiche deux enregistrements DNS à ajouter chez votre registrar — un CNAME (ou A/ALIAS pour un apex) et un TXT pour la vérification. Une fois les deux détectés, le SSL est provisionné automatiquement et le domaine entre en service, généralement en 5 à 30 minutes. Free et Starter ne prennent pas en charge les domaines personnalisés ; passez à un plan supérieur.

La plupart des problèmes viennent du DNS. Vérifiez que l'enregistrement CNAME (ou A/ALIAS) existe, pointe vers la valeur affichée par FloopFloop et n'est pas derrière un proxy bloquant notre vérification (le « nuage orange » de Cloudflare doit être désactivé jusqu'à la fin de la vérification — vous pourrez le réactiver après). Utilisez `dig votre-domaine.com +short` depuis un terminal pour voir ce que voit le monde. La vérification prend en général moins de 15 minutes ; si après une heure le tableau de bord reste sur « En attente », contactez le support avec le domaine.

Tous les secrets sont chiffrés au repos en AES-256 dans AWS Secrets Manager et déchiffrés uniquement au moment de la requête dans le runtime de votre projet — ils ne sont jamais écrits sur disque ni dans les logs de build. Une fois enregistré, un secret est en écriture seule : vous pouvez le mettre à jour ou le supprimer, mais pas le relire depuis le tableau de bord. Le personnel FloopFloop n'a pas accès aux valeurs en clair ; nous ne voyons que le nom de la clé et les métadonnées d'audit.

Oui. Ouvrez Paramètres → Secrets, trouvez l'entrée, cliquez sur « Rotation » et collez la nouvelle valeur. En environ 30 secondes, le runtime en cours commence à lire la nouvelle valeur (nous hot-reloadons les secrets sans redémarrer la fonction). Si le secret fait partie d'une config build-time (rare), une bannière vous demandera de redéployer — environ une minute, 1 crédit.

Dites à l'IA dans le chat : « ajoute un cron qui tourne tous les jours à 9 h et m'envoie un résumé des nouvelles inscriptions par e-mail ». L'IA génère une route `/api/cron/<nom>` dans votre code, enregistre la planification (expression cron ou intervalle) et notre scheduler garde l'enregistrement à jour à chaque redéploiement. Chaque exécution arrive avec un bearer token limité au projet, pour que seul notre scheduler puisse la déclencher. Les exécutions et les logs sont sous Paramètres → Planifications.

Sur macOS et Linux : `curl -fsSL https://floop.tech/install.sh | sh`. Sur Windows : téléchargez le dernier installeur depuis la page Releases GitHub du dépôt floop-cli, ou utilisez `winget install FloopFloopAI.floop`. Une fois installé, lancez `floop login` — un navigateur s'ouvre pour autoriser cet appareil. Ensuite, `floop new`, `floop refine`, `floop deploy` et les autres commandes fonctionnent sans configuration supplémentaire.

Un token CLI est la credential que `floop login` écrit dans votre config locale — il identifie l'humain sur un appareil donné, et vous pouvez le révoquer depuis /account/devices quand vous arrêtez d'utiliser un laptop. Une clé API sert à l'accès non assisté depuis des scripts, du CI ou des apps tierces — vous les créez sous /account/api-keys, pouvez les scoper par projet si vous voulez et les faire tourner à tout moment. Les deux appellent la même surface `/api/v1/*`, mais seules les clés API ont leur place dans des automatisations.

Oui — les huit SDK officiels (Node, Python, Go, Rust, Ruby, PHP, Swift, Kotlin) enveloppent tous la même surface `/api/v1/*` et exposent des noms de méthode identiques. Quand nous ajoutons un endpoint, nous le reflétons sur tous les SDK dans la même release. Le serveur MCP (`@floopfloop/mcp`) ré-expose le SDK Node aux agents LLM et reçoit la nouvelle méthode automatiquement. Si vous repérez un manque, c'est un bug — ouvrez une issue sur le dépôt SDK concerné.