# Kivo --- > A SaaS theme for software, AI, API, and dev tool startups: 4 homepages and about 38 page designs, including pricing, docs landing, changelog, and integrations. --- # Kivo Source: https://kivo-astro.pages.dev/fr/ > Déployez applications web, API, workers et agents IA sur un cloud pour développeurs avec mise à l'échelle, réseau et observabilité intégrés. --- # Tarifs Source: https://kivo-astro.pages.dev/fr/pricing/ > Des tarifs simples à l'usage. Commencez gratuitement et faites évoluer vos services, bases de données et workers. ## Une tarification simple qui suit votre croissance Payez à la seconde le calcul que vous utilisez, avec des limites claires et sans frais de bande passante cachés. ### Starter: $0 / mois Pour les projets personnels et les prototypes. - Sites statiques gratuits - Un service web gratuit - Support communautaire ### Team: $25 / mois (Annuel: $20 / mois) Pour les équipes en production. - Services illimités - Environnements de prévisualisation - Mise à l'échelle automatique - Support par e-mail ### Entreprise: Sur mesure Pour les organisations aux besoins avancés. - SSO et journaux d'audit - Support dédié - Revues de conformité - Contrats personnalisés ## Toutes les fonctionnalités, côte à côte ### Déploiements | Fonctionnalités | Starter | Team | Entreprise | | --- | --- | --- | --- | | Sites statiques | Illimités | Illimités | Illimités | | Services web | 1 | Illimités | Illimités | | Minutes de build par mois | 500 | 5 000 | Sur mesure | | Déploiements sans interruption | ✓ | ✓ | ✓ | | Environnements de prévisualisation | — | ✓ | ✓ | | Historique des retours arrière | 7 jours | 30 jours | 1 an | ### Mise à l'échelle et réseau | Fonctionnalités | Starter | Team | Entreprise | | --- | --- | --- | --- | | Mise à l'échelle automatique | — | ✓ | ✓ | | Domaines personnalisés | 2 | Illimités | Illimités | | Certificats TLS gérés | ✓ | ✓ | ✓ | | Réseau privé | — | ✓ | ✓ | | Régions | 1 | Toutes | Toutes | ### Espace de travail et sécurité | Fonctionnalités | Starter | Team | Entreprise | | --- | --- | --- | --- | | Membres de l'espace de travail | 1 | Illimités | Illimités | | Accès basé sur les rôles | — | ✓ | ✓ | | SSO | — | — | ✓ | | Journaux d'audit | — | — | ✓ | | Revues de conformité | — | — | ✓ | ### Support | Fonctionnalités | Starter | Team | Entreprise | | --- | --- | --- | --- | | Support communautaire | ✓ | ✓ | ✓ | | Support par e-mail | — | ✓ | ✓ | | SLA de disponibilité | — | 99,9 % | 99,99 % | | Support dédié | — | — | ✓ | | Contrats personnalisés | — | — | ✓ | --- # FAQ Source: https://kivo-astro.pages.dev/fr/faq/ > Réponses sur les offres, les langages pris en charge, la mise à l'échelle, les migrations, la localisation des données et la disponibilité. ## Existe-t-il une offre gratuite ? Oui. L'offre Starter inclut des sites statiques gratuits et un service web, ce qui suffit pour les projets personnels et les prototypes. ## Quels langages et frameworks sont pris en charge ? Node.js, Python, Go, Ruby, Rust, Elixir, PHP et tout ce qui tient dans un conteneur. La plupart des frameworks sont détectés automatiquement. ## Comment fonctionne la mise à l'échelle automatique ? Définissez un nombre minimum et maximum d'instances. Nous ajustons selon le CPU et la mémoire, vous ne payez que ce qui tourne. ## Puis-je migrer depuis un autre cloud ? La plupart des équipes migrent en une journée. Importez votre dépôt, recréez vos variables d'environnement et restaurez votre base depuis une sauvegarde. ## Où sont stockées mes données ? Dans la région choisie pour chaque service et base de données. Les sauvegardes sont chiffrées et restent dans la même région. ## Proposez-vous une garantie de disponibilité ? Les offres Team et Entreprise incluent un accord de niveau de service avec des crédits si l'objectif n'est pas atteint. --- # Documentation Source: https://kivo-astro.pages.dev/fr/docs/ > Documentation développeur : démarrages rapides pour les frameworks populaires, guides de déploiement et de bases de données, commandes CLI et référence de l'API REST. --- # Sécurité Source: https://kivo-astro.pages.dev/fr/security/ > Certifications, chiffrement, contrôle d'accès, surveillance et signalement des failles. Tout ce dont votre revue de sécurité a besoin, au même endroit. --- # À propos Source: https://kivo-astro.pages.dev/fr/about/ > L'équipe derrière la plateforme : pourquoi nous l'avons lancée, notre façon de construire, nos investisseurs et les postes ouverts. --- # Communauté Source: https://kivo-astro.pages.dev/fr/community/ > Rejoignez le chat de la communauté, le forum et GitHub. Découvrez la CLI et les SDK open source, participez aux permanences et aux meetups, et rencontrez les contributeurs. --- # Contacter l'équipe commerciale Source: https://kivo-astro.pages.dev/fr/contact/ > Contactez l'équipe commerciale pour les tarifs sur volume, les régions dédiées, le SSO, les revues de conformité et l'aide à la migration. --- # Mise à l'échelle automatique Source: https://kivo-astro.pages.dev/fr/services/service-01/ > Ajoutez et retirez des instances automatiquement selon le trafic, le CPU et la mémoire. ## Quand utiliser la mise à l'échelle automatique La mise à l'échelle automatique convient à tout service dont le trafic varie au fil de la journée : boutiques en ligne, API publiques, webhooks ou endpoints d'IA qui connaissent des pics après un lancement ou une campagne. Vous payez les instances que vous faites tourner, donc une nuit calme coûte moins cher qu'un après-midi chargé. ## Ce qui évolue et ce qui reste fixe Les services web et les services privés évoluent horizontalement. Chaque nouvelle instance exécute le même build et rejoint le même réseau privé : rien à reconfigurer. Les workers en arrière-plan peuvent évoluer selon la profondeur de leur file d'attente, et les bases de données évoluent séparément, avec leurs propres offres. - Mise à l'échelle horizontale des services web et privés - Mise à l'échelle des workers selon la file d'attente - Limites indépendantes pour chaque environnement ## Des coûts prévisibles Le nombre maximal d'instances est un plafond strict. Lorsqu'un service l'atteint, vous recevez une alerte et le service continue de tourner à cette taille. L'utilisation est facturée à la seconde, et la page d'utilisation indique précisément quand chaque instance a démarré et s'est arrêtée. --- # Réseau privé Source: https://kivo-astro.pages.dev/fr/services/service-02/ > Reliez services, bases de données et workers sur un réseau isolé, sans exposition publique. ## Pourquoi c'est important Dans une application moderne, la majeure partie du trafic n'a jamais besoin de quitter votre infrastructure. Une API échange avec sa base de données, un worker lit une file d'attente, un frontend appelle un backend. Un réseau privé tient ce trafic à l'écart de l'Internet public, ce qui supprime toute une catégorie de surfaces d'attaque et accélère chaque requête. ## Ce que vous obtenez Chaque espace de travail dispose d'un réseau privé par région et par environnement. Les services le rejoignent automatiquement à leur déploiement et sont joignables via un nom d'hôte stable qui ne change pas d'une version à l'autre. - Trafic chiffré entre les services - DNS interne pour chaque service et chaque base de données - Entrée publique uniquement là où vous l'activez ## Se connecter depuis l'extérieur Lorsque vous devez accéder à un service privé depuis votre ordinateur, ouvrez un tunnel temporaire avec la CLI. Les tunnels sont liés à votre compte, consignés dans le journal d'audit et se ferment automatiquement à la déconnexion. --- # Environnements de prévisualisation Source: https://kivo-astro.pages.dev/fr/services/service-03/ > Obtenez une copie complète de votre stack pour chaque pull request, supprimée au merge. ## Pourquoi les prévisualisations changent la revue de code Lire un diff vous dit ce qui a changé. Parcourir une copie en fonctionnement vous dit si ça marche. Les environnements de prévisualisation offrent aux designers, aux product managers et à la QA la même vue que celle de l'utilisateur final, avant que quoi que ce soit n'arrive en production. ## Ce qui est copié Les prévisualisations sont créées à partir du même fichier de configuration que la production, l'architecture est donc toujours identique. Vous choisissez quels services y participent et quelle taille leur donner. - Chaque service web, worker et tâche cron de votre configuration - Des bases de données créées à neuf, pré-remplies ou restaurées depuis un snapshot - Des variables d'environnement issues d'un groupe dédié aux prévisualisations ## Des coûts maîtrisés Les copies de prévisualisation peuvent tourner sur des offres plus légères que la production, et elles s'arrêtent automatiquement à la fermeture de la pull request ou à l'expiration que vous avez fixée. Vous payez à la seconde, uniquement pendant qu'une prévisualisation tourne. --- # Déploiements sans coupure Source: https://kivo-astro.pages.dev/fr/services/service-04/ > Publiez chaque version derrière des contrôles de santé et revenez en arrière en un clic. ## Pourquoi les déploiements cassent, et comment nous l'évitons La plupart des pannes pendant une mise en production viennent de l'intervalle entre l'arrêt de l'ancienne version et le démarrage de la nouvelle, ou d'une nouvelle version qui démarre sans parvenir à servir les requêtes. Les déploiements sans coupure suppriment cet intervalle : l'ancienne version continue de répondre jusqu'à ce que la nouvelle ait prouvé qu'elle est saine. ## Ce qui se passe à chaque déploiement Aucune configuration n'est nécessaire pour bénéficier de déploiements sûrs. Un contrôle de santé par défaut s'exécute sur chaque service web, et vous pouvez le diriger vers votre propre endpoint pour une vérification plus stricte. - Les nouvelles instances démarrent avant l'arrêt des anciennes - Le trafic ne bascule qu'après la réussite des contrôles de santé - Un déploiement en échec ne reçoit jamais de trafic ## Revenir en arrière Chaque build réussi est conservé comme cible de retour arrière. Revenir en arrière redirige le trafic vers une image existante : cela prend quelques secondes au lieu d'un build complet. Les migrations de base de données ne sont pas annulées automatiquement, veillez donc à ce qu'elles restent rétrocompatibles. --- # Infrastructure as code Source: https://kivo-astro.pages.dev/fr/services/service-05/ > Décrivez services, bases de données et environnements dans un seul fichier de config versionné. ## Pourquoi garder l'infrastructure dans votre dépôt Les paramètres qui n'existent que dans un tableau de bord sont difficiles à relire, difficiles à dupliquer et faciles à perdre. Avec votre stack dans un fichier de config, chaque modification passe par le même processus de pull request que votre code, et un nouvel environnement n'est qu'à une commande. ## Ce que le fichier peut décrire La config couvre tout ce que la plateforme exécute pour vous. Tout ce que vous pouvez régler dans le tableau de bord a un champ correspondant dans le fichier. - Services web, services privés, workers et tâches cron - Postgres géré et caches en mémoire - Ensembles de variables, domaines et règles de mise à l'échelle ## Travailler avec le tableau de bord Vous pouvez toujours faire des modifications rapides dans le tableau de bord. Lorsque la stack en production s'écarte du fichier, un avertissement s'affiche : vous pouvez alors mettre à jour le fichier ou laisser la prochaine synchronisation annuler la modification. --- # CLI et API Source: https://kivo-astro.pages.dev/fr/services/service-06/ > Pilotez déploiements, logs et mise à l'échelle depuis votre terminal ou n'importe quel pipeline CI. ## Pensé pour l'automatisation Passer par le tableau de bord convient très bien pour un premier déploiement. Ensuite, la plupart des équipes veulent que les déploiements suivent les tests, que les environnements soient créés par des scripts et que les ingénieurs d'astreinte consultent les logs sans quitter le terminal. La CLI et l'API le permettent sans outillage supplémentaire. ## Ce que vous pouvez automatiser Chaque action du tableau de bord est disponible via l'API, et la CLI regroupe les plus courantes dans des commandes courtes. - Déploiements, retours arrière et promotions entre environnements - Règles de mise à l'échelle, variables d'environnement et domaines - Logs, métriques et accès shell pour le débogage ## Clés et permissions Les clés d'API sont rattachées à un espace de travail et peuvent être limitées à un accès en lecture seule ou à certains services. Chaque appel effectué avec une clé est enregistré dans le journal d'audit avec le nom de la clé : les modifications automatisées sont ainsi aussi traçables que les modifications manuelles. --- # Webhooks Source: https://kivo-astro.pages.dev/fr/services/service-11/ > Envoyez les événements de déploiement, de mise à l'échelle et d'incident vers vos endpoints, signés et relancés. ## Types d'événements Les événements sont nommés `ressource.action`, si bien qu'un endpoint peut suivre tout un pan de la plateforme. Les plus utilisés sont `deploy.succeeded`, `deploy.failed`, `service.scaled` et `incident.opened`. Chaque charge utile inclut l'espace de travail, le service et un lien vers le tableau de bord. ## Vérifier les signatures Chaque requête contient un en-tête `Webhook-Signature` : un horodatage et un HMAC du corps brut, calculé avec le secret de l'endpoint. Comparez-le à votre propre HMAC et rejetez les requêtes de plus de cinq minutes pour bloquer les rejeux. ## Relances et ordre Une livraison réussit quand votre endpoint répond avec un statut 2xx en moins de dix secondes. Tout le reste est relancé avec un délai croissant pendant 24 heures. Les événements peuvent arriver dans le désordre : utilisez le champ `created_at` et l'identifiant de l'événement plutôt que l'heure d'arrivée. --- # Secrets et variables d'environnement Source: https://kivo-astro.pages.dev/fr/services/service-12/ > Gardez clés, jetons et réglages hors de votre code, chiffrés et propres à chaque environnement. ## Comment la configuration atteint votre code Chaque service lit ses réglages dans des variables d'environnement au démarrage. La plateforme construit cette liste à partir de trois sources, dans l'ordre : les groupes partagés, les valeurs définies sur le service et les valeurs liées à d'autres ressources comme les bases de données. Une valeur plus tardive remplace une valeur antérieure de même clé : un service peut donc surcharger un groupe sans le modifier pour tous. ## Variables et secrets Les deux sont stockés de la même façon, chiffrés au repos, et injectés de la même façon dans le service. La différence tient à qui peut les relire. ### Variables simples Utilisez des variables simples pour les réglages que toute l'équipe peut voir : niveaux de log, drapeaux de fonctionnalité, URL publiques. Leurs valeurs apparaissent dans le tableau de bord et dans la sortie de la CLI. ### Secrets Utilisez des secrets pour tout ce qui donne un accès : jetons d'API, clés de signature, mots de passe. Une fois enregistrée, la valeur d'un secret n'est plus jamais affichée. Vous pouvez la remplacer ou la supprimer, et chaque changement est inscrit dans le journal d'audit. ## Groupes partagés Un groupe est un ensemble nommé de variables utilisé par plusieurs services. Modifiez une valeur du groupe et chaque service lié la récupère à son prochain déploiement. - Un groupe par sujet, comme `shared-config` ou `payments` - Les groupes peuvent être limités à certains environnements - Un service peut lier plusieurs groupes ## Environnements et aperçus Chaque environnement a ses propres valeurs. La production, la préproduction et les environnements d'aperçu ne partagent jamais de secrets, sauf si vous leur liez le même groupe. Les environnements d'aperçu copient par défaut les valeurs de préproduction : une pull request ne voit donc jamais les identifiants de production. ## Faire tourner un secret La rotation se fait en deux étapes, pour que rien ne casse entre les deux : 1. Ajoutez la nouvelle valeur sous une seconde clé et déployez le code qui la lit. 2. Supprimez l'ancienne clé quand plus rien ne l'utilise. ```yaml title="stack.yaml" envVars: - key: API_TOKEN_NEXT sync: false ``` ## Limites Un service peut contenir jusqu'à 500 variables, et une valeur peut atteindre 32 Ko. Pour les fichiers plus volumineux, comme les certificats, stockez-les en fichiers secrets et lisez-les depuis le disque. --- # Métriques et logs Source: https://kivo-astro.pages.dev/fr/services/service-13/ > Latence, erreurs et chaque ligne de log de chaque service dans un seul tableau de bord, avec des alertes qui joignent la bonne personne. ## Intégré, pas ajouté après coup Chaque service envoie ses métriques et ses logs à la plateforme dès son premier déploiement. Rien à installer, aucun échantillonnage à configurer. Pour une rétention plus longue ou vos propres outils, transférez les logs vers n'importe quel endpoint syslog ou HTTP. ## De l'alerte au correctif Une alerte mène directement à la métrique qui l'a déclenchée, aux logs de cette minute et au déploiement en ligne. La plupart des incidents se terminent par un retour arrière depuis le même écran. --- # Livrez des applications d'IA sans gérer de GPU Source: https://kivo-astro.pages.dev/fr/solutions/ai-apps/ > Déployez agents d'IA, API d'inférence et pipelines RAG avec tâches en arrière-plan durables, réseau privé et autoscaling intégrés. --- # Lancez cette semaine, passez à l'échelle l'an prochain Source: https://kivo-astro.pages.dev/fr/solutions/startups/ > Déployez à chaque push, obtenez un environnement de prévisualisation par pull request et passez à l'échelle sans recrutement ops. Gratuit pour démarrer, avec des crédits pour les jeunes équipes. --- # Tous vos projets clients, un seul flux serein Source: https://kivo-astro.pages.dev/fr/solutions/agencies/ > Hébergez sites et applications clients dans des espaces séparés, partagez des environnements de prévisualisation pour validation et transférez les projets au lancement. --- # La vitesse d'une plateforme, les contrôles d'une grande entreprise Source: https://kivo-astro.pages.dev/fr/solutions/enterprises/ > Déploiements en libre-service pour les grandes équipes, avec authentification unique, journaux d'audit, réseau privé, contrôles de conformité et support dédié. --- # Branchyard Source: https://kivo-astro.pages.dev/fr/integrations/branchyard/ > Construisez depuis des serveurs Branchyard auto-hébergés, y compris sur des réseaux privés. ## Présentation Branchyard tourne sur vos propres serveurs. L'intégration se connecte par un webhook signé et une clé de déploiement en lecture seule : les builds démarrent au push sans exposer votre réseau à Internet. ## Fonctionnalités - Webhooks signés avec rotation automatique des clés - Clés de déploiement en lecture seule limitées à un dépôt - Compatible avec les instances privées et isolées ## Configuration 1. Ajoutez l'URL de votre serveur Branchyard dans **Intégrations → Branchyard**. 2. Copiez l'URL et le secret du webhook dans les paramètres de votre projet Branchyard. 3. Ajoutez la clé de déploiement générée au dépôt. ```shell title="Terminal" $ cloud integrations add branchyard --url https://git.internal.example ``` --- # Cachefront Source: https://kivo-astro.pages.dev/fr/integrations/cachefront/ > Cache clé-valeur à faible latence sur le réseau privé. ## Présentation Cachefront tourne à côté de vos services et n'est accessible que par le réseau privé. Utilisez-le pour les sessions, les limites de débit et les résultats de requêtes fréquentes, sans ajouter de point d'accès public. ## Fonctionnalités - Réseau privé uniquement, aucun point d'accès public - Même région que vos services - Métriques dans le tableau de bord du service ## Configuration 1. Créez un cache dans **Intégrations → Cachefront**. 2. Choisissez les services autorisés à s'y connecter. 3. Lisez `CACHE_URL` dans votre environnement. ```shell title="Terminal" $ cloud integrations add cachefront --plan small --services api,worker ``` --- # Channelbot Source: https://kivo-astro.pages.dev/fr/integrations/channelbot/ > Publiez déploiements, alertes et prévisualisations dans le chat de votre équipe. ## Présentation Channelbot publie un message quand un déploiement démarre, réussit ou échoue, avec un lien vers les logs. Les environnements de prévisualisation sont annoncés dans le fil de la pull request pour que les relecteurs les ouvrent tout de suite. ## Fonctionnalités - Messages de déploiement et d'alerte par canal - Liens de prévisualisation dans les fils de pull request - Retour arrière depuis un bouton du message ## Configuration 1. Installez Channelbot dans votre espace de chat. 2. Connectez-le dans **Intégrations → Channelbot**. 3. Choisissez un canal pour chaque service. ```shell title="Terminal" $ cloud integrations add channelbot --channel deploys --services web,api ``` --- # Commitline Source: https://kivo-astro.pages.dev/fr/integrations/commitline/ > Déployez à chaque push et ouvrez un environnement de prévisualisation pour chaque pull request. ## Présentation Connectez un dépôt Commitline et la plateforme construit et déploie chaque push sur votre branche de production. Chaque pull request obtient son propre environnement de prévisualisation, et le statut du déploiement remonte comme vérification de commit. ## Fonctionnalités - Déploiement à chaque push sur la branche de votre choix - Un environnement de prévisualisation par pull request - Statut et logs du déploiement liés à chaque vérification de commit ## Configuration 1. Ouvrez **Paramètres de l'espace de travail → Intégrations** et choisissez Commitline. 2. Autorisez l'accès aux dépôts à déployer. 3. Liez un dépôt à un service depuis la CLI ou le tableau de bord. ```shell title="Terminal" $ cloud link --repo commitline:acme/web-frontend --branch main ``` --- # Directory Sync Source: https://kivo-astro.pages.dev/fr/integrations/directory-sync/ > Ajoutez et retirez les membres automatiquement avec SCIM. ## Présentation Directory Sync aligne les membres de l'espace de travail sur l'annuaire de votre entreprise. Les nouveaux arrivants ont accès dès le premier jour, et l'accès est retiré dès qu'une personne part. ## Fonctionnalités - Ajout et retrait via SCIM 2.0 - Groupes synchronisés avec les rôles - Chaque changement dans le journal d'audit ## Configuration 1. Générez un jeton SCIM dans **Sécurité → Directory Sync**. 2. Ajoutez le point d'accès et le jeton à votre annuaire. 3. Attribuez les groupes qui doivent avoir accès. ```shell title="Terminal" $ cloud scim token create --name company-directory ``` --- # Embedstore Source: https://kivo-astro.pages.dev/fr/integrations/embedstore/ > Stockez et interrogez des embeddings vectoriels pour la recherche et les fonctions d'IA. ## Présentation Embedstore garde les embeddings vectoriels près de vos données et répond aux requêtes de similarité par le réseau privé. Les mises à jour d'index tournent en tâches en arrière-plan : votre API reste rapide. ## Fonctionnalités - Recherche par similarité sur le réseau privé - Mises à jour d'index en tâches en arrière-plan - Collections par environnement ## Configuration 1. Ajoutez Embedstore dans **Intégrations → Embedstore**. 2. Créez une collection et choisissez la taille des vecteurs. 3. Lisez `EMBEDSTORE_URL` dans votre environnement. ```shell title="Terminal" $ cloud integrations add embedstore --collection docs --dimensions 1536 ``` --- # Event Stream Source: https://kivo-astro.pages.dev/fr/integrations/event-stream/ > Transférez logs et métriques vers votre stack d'observabilité. ## Présentation Event Stream envoie les logs de vos services, les événements de déploiement et les métriques d'instance vers n'importe quel point d'accès HTTPS ou syslog. Filtrez par service et par niveau, et regroupez les événements pour limiter les coûts d'ingestion. ## Fonctionnalités - Logs, métriques et événements de déploiement dans un seul flux - Filtres par service, environnement et niveau - Regroupement et nouvelles tentatives progressives ## Configuration 1. Ouvrez **Intégrations → Event Stream** et ajoutez une destination. 2. Choisissez les services et niveaux de log à transférer. 3. Envoyez un événement de test pour vérifier la connexion. ```shell title="Terminal" $ cloud integrations add event-stream --url https://logs.example.com/ingest --level warn ``` --- # Gatecheck CI Source: https://kivo-astro.pages.dev/fr/integrations/gatecheck-ci/ > Bloquez les déploiements jusqu'à la réussite de vos tests, puis promouvez le build. ## Présentation Gatecheck CI exécute vos tests, et la plateforme attend un résultat positif avant de déployer. Vous promouvez l'image exacte qui a passé les tests : ce que vous avez testé est ce qui part en production. ## Fonctionnalités - Déploiement uniquement après les vérifications requises - Promotion de l'image testée, sans nouveau build - Retour arrière depuis le pipeline en une étape ## Configuration 1. Créez un jeton d'API avec le scope `deploys:write`. 2. Enregistrez-le comme secret dans Gatecheck CI. 3. Ajoutez l'étape de déploiement à la fin de votre pipeline. ```shell title="Terminal" $ cloud deploy --service api --image $CI_IMAGE --wait ``` --- # Keygate Source: https://kivo-astro.pages.dev/fr/integrations/keygate/ > Authentification unique pour votre espace de travail avec SAML ou OpenID Connect. ## Présentation Keygate permet aux membres de se connecter au tableau de bord et à la CLI avec votre fournisseur d'identité. Imposez le SSO à tout l'espace de travail et associez les groupes aux rôles. ## Fonctionnalités - SAML 2.0 et OpenID Connect - SSO obligatoire pour chaque membre - Association des groupes aux rôles ## Configuration 1. Ouvrez **Paramètres de l'espace de travail → Sécurité → Keygate**. 2. Importez les métadonnées de votre fournisseur d'identité. 3. Testez la connexion, puis activez l'obligation. ```shell title="Terminal" $ cloud sso configure --provider keygate --metadata ./idp-metadata.xml ``` --- # Letterbolt Source: https://kivo-astro.pages.dev/fr/integrations/letterbolt/ > Envoyez des e-mails transactionnels depuis vos services avec des domaines vérifiés. ## Présentation Letterbolt envoie réinitialisations de mot de passe, reçus et alertes depuis votre propre domaine. L'intégration ajoute les enregistrements DNS pour vous et définit la clé d'API comme variable d'environnement. ## Fonctionnalités - Enregistrements DNS d'envoi ajoutés automatiquement - Clé d'API définie comme variable d'environnement - Événements de livraison dans Event Stream ## Configuration 1. Connectez Letterbolt dans **Intégrations → Letterbolt**. 2. Choisissez le domaine d'envoi et validez les enregistrements DNS. 3. Lisez `LETTERBOLT_API_KEY` dans votre environnement. ```shell title="Terminal" $ cloud integrations add letterbolt --domain mail.example.com ``` --- # Oncall Relay Source: https://kivo-astro.pages.dev/fr/integrations/oncall-relay/ > Alertez l'ingénieur d'astreinte quand un déploiement échoue ou qu'un service tombe. ## Présentation Oncall Relay transforme les alertes de la plateforme en incidents. Déploiements en échec, contrôles de santé défaillants et limites d'autoscaling alertent la bonne rotation, et l'incident se ferme quand le service se rétablit. ## Fonctionnalités - Incidents pour les déploiements et contrôles de santé en échec - Routage par service et environnement - Résolution automatique au rétablissement ## Configuration 1. Créez une clé d'intégration dans Oncall Relay. 2. Collez-la dans **Intégrations → Oncall Relay**. 3. Associez les services aux politiques d'escalade. ```shell title="Terminal" $ cloud integrations add oncall-relay --policy backend-primary ``` --- # Rowmesh Source: https://kivo-astro.pages.dev/fr/integrations/rowmesh/ > Associez une base Postgres serverless, avec une branche par environnement de prévisualisation. ## Présentation Rowmesh donne à chaque environnement de prévisualisation sa propre branche de base de données, copiée depuis la production en quelques secondes. La chaîne de connexion est définie comme variable d'environnement et supprimée à la fermeture de la prévisualisation. ## Fonctionnalités - Une branche de base par environnement de prévisualisation - Chaînes de connexion définies comme variables d'environnement - Branches supprimées à la fermeture de la pull request ## Configuration 1. Connectez votre projet Rowmesh dans **Intégrations → Rowmesh**. 2. Choisissez la branche parente à copier pour les prévisualisations. 3. Redéployez le service pour recevoir `DATABASE_URL`. ```shell title="Terminal" $ cloud integrations add rowmesh --project analytics --branch-from main ``` --- # Secretkeep Source: https://kivo-astro.pages.dev/fr/integrations/secretkeep/ > Synchronisez les secrets de votre coffre-fort dans les variables d'environnement à chaque déploiement. ## Présentation Gardez vos secrets dans Secretkeep et référencez-les par leur chemin. Au déploiement, la plateforme lit les valeurs à jour et les injecte comme variables d'environnement : rien de sensible n'est stocké dans votre dépôt. ## Fonctionnalités - Secrets référencés par chemin dans la configuration du service - Valeurs rafraîchies à chaque déploiement - Accès consignés dans le journal d'audit de l'espace de travail ## Configuration 1. Créez une politique Secretkeep en lecture seule pour la plateforme. 2. Ajoutez le jeton de la politique dans **Intégrations → Secretkeep**. 3. Remplacez les valeurs en clair par des références `secretkeep://`. ```shell title="Terminal" $ cloud env set DATABASE_URL=secretkeep://prod/db/url --service api ``` --- # Spanlight Source: https://kivo-astro.pages.dev/fr/integrations/spanlight/ > Tracez les requêtes entre vos services avec OpenTelemetry. ## Présentation Spanlight collecte les traces OpenTelemetry de chaque service et les relie au déploiement qui les a produites. Trouvez la portion lente, puis remontez à la version qui l'a introduite. ## Fonctionnalités - Collecteur OpenTelemetry configuré pour vous - Traces étiquetées par service et déploiement - Échantillonnage réglé par environnement ## Configuration 1. Ajoutez votre clé d'API Spanlight dans **Intégrations → Spanlight**. 2. Choisissez un taux d'échantillonnage par environnement. 3. Redéployez pour commencer à envoyer des traces. ```shell title="Terminal" $ cloud integrations add spanlight --sample-rate 0.2 --env production ``` --- # Comment Brightlane Labs a divisé par deux le temps de revue de code grâce aux environnements de prévisualisation Source: https://kivo-astro.pages.dev/fr/customers/brightlane-labs/ > Un éditeur d'outils de design a donné à chaque pull request sa propre URL en ligne : designers, PM et ingénieurs relisent le vrai produit. ## Le défi Brightlane Labs développe un outil de design collaboratif utilisé par des équipes produit. Les revues passaient par des captures et des enregistrements d'écran, car seuls les ingénieurs pouvaient lancer une branche en local. Les retours arrivaient tard, souvent après la fusion, et un serveur de pré-production partagé faisait qu'une seule branche cassée bloquait les tests de tout le monde. ## La solution L'équipe a activé les environnements de prévisualisation sur le dépôt principal. Chaque pull request reçoit désormais une copie complète de la stack, avec une branche de base de données alimentée en données de test et sa propre URL publiée en commentaire. Designers et chefs de produit relisent la version en ligne dans le navigateur. À la fermeture de la pull request, l'environnement et ses données sont supprimés : rien ne traîne sur la facture. ## Les résultats Des boucles de revue qui duraient des jours se bouclent maintenant en un après-midi. Le serveur de pré-production partagé a disparu, et le rythme des versions a triplé, car les changements fusionnés ont déjà été testés par ceux qui les avaient demandés. --- # Comment Crestfield Digital s'est débarrassé de 40 scripts de sauvegarde Source: https://kivo-astro.pages.dev/fr/customers/crestfield-digital/ > Un groupe média a remplacé ses scripts de sauvegarde et de restauration écrits à la main par Postgres managé et l'infrastructure as code. ## Le défi Crestfield Digital publie l'actualité et les podcasts d'une douzaine de titres régionaux. Sa petite équipe maintenait 40 scripts shell pour les sauvegardes de bases de données, les restaurations et le renouvellement des certificats, chacun écrit par quelqu'un qui avait depuis quitté l'entreprise. Un test de restauration raté a révélé que deux sauvegardes étaient vides depuis des mois, sans qu'aucune alerte ne le signale. ## La solution L'équipe a migré ses bases vers Postgres managé avec restauration à un instant donné, et a décrit chaque service et chaque base dans un fichier de configuration versionné dans le dépôt. Une restauration se résume désormais à une seule commande de la CLI, que n'importe qui dans l'équipe peut lancer. ```shell title="Terminal" $ cloud db restore newsroom-db --to "2026-03-30 08:15" ``` ## Les résultats Les 40 scripts ont disparu. Chaque base peut être restaurée à n'importe quel instant de la semaine écoulée, et l'équipe récupère six heures par semaine pour les fonctionnalités que ses rédactions réclamaient. --- # Comment Halcyon Health a réussi son audit de sécurité grâce au réseau privé Source: https://kivo-astro.pages.dev/fr/customers/halcyon-health/ > Un éditeur de prise de rendez-vous médicaux a placé ses services de données patients sur un réseau privé et ramené la préparation de ses audits de plusieurs semaines à quelques jours. ## Le défi Halcyon Health gère la prise de rendez-vous de cliniques : ses services traitent les noms des patients, leurs coordonnées et l'historique de leurs visites. Chaque audit de sécurité annuel exigeait des semaines de collecte de règles de pare-feu et de captures d'écran pour prouver quels services pouvaient atteindre quelles bases. Plusieurs services internes exposaient encore des points d'accès publics, protégés seulement par des listes d'adresses IP autorisées que personne n'osait modifier. ## La solution L'équipe a placé ses 22 services sur un réseau privé et supprimé les points d'accès publics de tout ce qui n'était pas le service web destiné aux patients. Les règles d'accès vivent dans le même fichier de configuration que les services : chaque changement passe donc par une revue de code. Les environnements de prévisualisation tournent sur leurs propres réseaux isolés avec des données synthétiques, si bien que les tests ne touchent jamais de vrais dossiers patients. ## Les résultats L'audit de sécurité suivant a pris trois jours. Les auditeurs ont lu les règles réseau directement dans l'historique du dépôt, et aucune base n'est accessible depuis Internet. --- # Comment Northstar Systems a réduit ses temps de déploiement de 80 % Source: https://kivo-astro.pages.dev/fr/customers/northstar-systems/ > Une équipe de paiement a migré 40 services hors de VM configurées à la main en un week-end et déploie désormais en production plus d'une dizaine de fois par jour. ## Le défi Northstar Systems traite les paiements par carte de marchands en ligne dans toute l'Europe. Sa plateforme comptait 40 services sur des machines virtuelles qu'une équipe ops de deux personnes configurait à la main. Chaque mise en production partait le mardi ou le jeudi. Un déploiement occupait presque tout un après-midi, exigeait une fenêtre de maintenance pour les changements de base de données et bloquait les autres équipes pendant son exécution. Les ingénieurs regroupaient leurs changements pour limiter ce coût, si bien que chaque version portait plus de risques que la précédente. ## La solution L'équipe a décrit ses services, son réseau privé et ses variables d'environnement dans un seul fichier `cloud.yaml`, puis a relié le dépôt avec la CLI. Une copie de pré-production de la stack a tourné en parallèle pendant deux semaines pour comparer latence et taux d'erreur. ```yaml title="cloud.yaml" services: - name: payments-api type: web healthCheckPath: /healthz scaling: { minInstances: 3, maxInstances: 12 } - name: ledger-worker type: worker ``` Le week-end de bascule, ils ont basculé le DNS service par service. Grâce aux déploiements sans coupure, l'API de paiement n'a perdu aucune requête, et le réseau privé a gardé la base du grand livre hors d'Internet. ## Les résultats Chaque fusion sur `main` part désormais en production. Des contrôles de santé valident chaque déploiement et un contrôle en échec déclenche un retour arrière automatique : les ingénieurs ont cessé de regrouper leur travail. L'équipe ops s'occupe maintenant des outils antifraude au lieu de corriger des serveurs. --- # Comment Orbit Commerce a continué à livrer en pleine haute saison Source: https://kivo-astro.pages.dev/fr/customers/orbit-commerce/ > Une plateforme de commerce a déployé plus de 100 fois pendant la semaine la plus chargée de l'année, sans une minute d'interruption. ## Le défi Orbit Commerce fait tourner les boutiques en ligne de centaines de marques. Chaque année, l'équipe gelait le code pendant six semaines autour des fêtes, car un mauvais déploiement en pleine affluence pouvait couper le paiement de tous les marchands à la fois. Le gel protégeait le site, mais les correctifs urgents attendaient des semaines et les fonctionnalités glissaient à l'année suivante. ## La solution Le paiement, la recherche et les stocks sont passés aux déploiements sans coupure, avec des contrôles de santé à chaque version. Les nouvelles instances démarrent, passent leurs contrôles et reçoivent du trafic avant que les anciennes ne se vident ; un contrôle en échec déclenche seul le retour arrière. L'autoscaling absorbe les pics de trafic dans trois régions, et les environnements de prévisualisation permettent aux marchands de tester leurs changements saisonniers avant la mise en ligne. ## Les résultats Pour la première fois, aucun gel du code. L'équipe a effectué 120 déploiements pendant la semaine la plus chargée de l'année sans aucune interruption, et les marchands ont reçu leurs fonctionnalités saisonnières à temps. --- # Comment une équipe de quatre chez Summit Cloud fait tourner des charges IA à grande échelle Source: https://kivo-astro.pages.dev/fr/customers/summit-cloud/ > Une startup IA fait tourner des API d'inférence et des tâches en arrière-plan pour des millions de requêtes par jour, sans équipe ops dédiée. ## Le défi Summit Cloud transforme de grands ensembles de documents en bases de connaissances interrogeables. Sa première version tournait sur des clusters autogérés, et les ingénieurs fondateurs passaient plus de temps sur les files d'attente, les scripts de mise à l'échelle et les certificats que sur le produit. Avec la croissance des clients, la charge est devenue irrégulière : un seul import pouvait ajouter des centaines de milliers de tâches en arrière-plan en quelques minutes. ## La solution L'équipe a séparé le produit en un service web pour l'API et des workers pour les tâches en arrière-plan, tous définis dans un seul fichier de configuration et déployés depuis le même dépôt. Les workers montent en charge selon la profondeur de la file, l'API selon la latence des requêtes. La CLI et l'API leur permettent de scripter les nouveaux environnements clients, et le réseau privé rend la base vectorielle accessible uniquement depuis leurs propres services. ## Les résultats Quatre ingénieurs font désormais tourner toute la plateforme, astreinte comprise. Les gros imports se terminent en quelques minutes au lieu de plusieurs heures, et le temps autrefois consacré à l'infrastructure va au produit. --- # Comment VectorGrid a absorbé un pic de lancement de 50× sans une seule alerte Source: https://kivo-astro.pages.dev/fr/customers/vectorgrid/ > Une plateforme d'analytics est passée d'une charge stable à cinquante fois son trafic habituel le jour du lancement, puis est redescendue, sans aucune intervention manuelle. ## Le défi Les tableaux de bord de VectorGrid sont utilisés par des milliers d'équipes, et un lancement public promettait un pic important mais impossible à chiffrer. L'ancienne infrastructure avait une taille fixe : l'équipe payait la capacité de pointe tout le mois ou risquait de tomber le jour où cela comptait le plus. ## La solution Ils ont défini des règles de mise à l'échelle sur le CPU et la latence des requêtes pour chaque service web, avec un nombre minimal d'instances pour le trafic du matin et un plafond pour limiter les dépenses. Les workers de requêtes sont passés derrière le réseau privé pour monter en charge selon la profondeur de la file, sans exposer de point d'accès. Avant le lancement, l'équipe a rejoué le trafic de production à 60 fois son niveau habituel sur une copie de pré-production pour vérifier que les limites tenaient. ## Les résultats Le jour du lancement, le trafic a atteint 50 fois la moyenne en deux heures. Les nouvelles instances ont démarré en quelques secondes, la latence est restée stable et personne n'a été alerté. Le lendemain matin, les services étaient redescendus d'eux-mêmes, et la facture de calcul du mois est passée sous celle de l'ancienne infrastructure fixe. --- # Plateforme vs Kubernetes maison Source: https://kivo-astro.pages.dev/fr/compare/diy-kubernetes/ > Comparez la plateforme avec un Kubernetes géré par vos soins : mise en place, mises à jour, autoscaling, environnements de prévisualisation et heures passées en exploitation. --- # Plateforme vs PaaS historique Source: https://kivo-astro.pages.dev/fr/compare/legacy-paas/ > Comparez la plateforme avec un PaaS de première génération : tarification, réseau privé, environnements de prévisualisation, autoscaling et choix des régions. --- # Plateforme vs VPS classique Source: https://kivo-astro.pages.dev/fr/compare/traditional-vps/ > Comparez la plateforme avec des serveurs privés virtuels : déploiements, correctifs, sauvegardes, mise à l'échelle et coût réel de vos propres machines. --- # Voici les workflows durables Source: https://kivo-astro.pages.dev/fr/blog/introducing-durable-workflows/ > Exécutez des tâches en plusieurs étapes qui résistent aux déploiements, aux plantages et aux timeouts. Chaque étape est sauvegardée, relancée et rejouable depuis le tableau de bord. Les tâches en arrière-plan commencent simplement, puis finissent en empilement de files d'attente, d'entrées cron et de tables de relance. Les workflows durables remplacent tout cela par du code ordinaire : vous écrivez les étapes dans l'ordre, et la plateforme s'assure que chacune va jusqu'au bout, même si un déploiement ou un plantage l'interrompt. Les workflows durables sont disponibles dès aujourd'hui sur toutes les offres. ## Comment s'exécute un workflow Un workflow est une fonction composée d'étapes nommées. Quand une étape se termine, son résultat est enregistré comme point de reprise. Si le processus s'arrête, l'exécution suivante saute les étapes terminées et reprend au dernier point de reprise, avec les mêmes entrées. ```ts title="workflows/send-invoices.ts" import { workflow, step } from "@cloud/workflows"; export default workflow("send-invoices", async () => { const accounts = await step("load", () => loadAccounts()); const invoices = await step("render", () => renderInvoices(accounts)); await step("send", { retries: 5, timeout: "2m" }, () => sendAll(invoices)); }); ``` Chaque étape doit pouvoir être relancée sans risque. Une bonne règle : écrire le résultat d'une étape à un seul endroit, avec une clé d'idempotence, pour qu'une relance n'envoie jamais deux fois la même facture. ## Le lancer depuis votre application Un workflow démarre depuis un appel API, une planification ou un autre workflow. L'appel renvoie immédiatement un identifiant d'exécution : votre gestionnaire de requête n'attend jamais la fin du travail. ```ts title="app/billing.ts" import { workflows } from "@cloud/sdk"; const run = await workflows.start("send-invoices", { month: "2026-10" }); console.log(run.id); // wf_run_8f2c... ``` ## Déboguer une exécution en échec Chaque exécution a une chronologie dans le tableau de bord, avec l'entrée, la sortie, la durée et les journaux de chaque étape. Quand une étape échoue après sa dernière relance, l'exécution se met en pause au lieu de disparaître. Corrigez le bug, déployez, puis rejouez l'exécution à partir de l'étape en échec. ```bash cloud workflows replay wf_run_8f2c --from send ``` ## Limites et tarifs Les workflows sont facturés comme du calcul classique. Les points de reprise et les rejeux sont inclus. Une exécution peut durer jusqu'à 30 jours, et une étape peut renvoyer jusqu'à 1 Mo de données. La liste complète des limites figure dans le changelog. --- # Comment nous avons divisé les démarrages à froid par deux Source: https://kivo-astro.pages.dev/fr/blog/cutting-cold-starts-in-half/ > Le cache d'instantanés, le chargement différé des modules et le changement de routage qui ont fait passer le démarrage à froid médian d'un service Node de 410 ms à 190 ms. Un démarrage à froid, c'est le temps entre l'arrivée d'une requête et le moment où une nouvelle instance est prête à y répondre. Pour les services qui descendent à zéro instance, c'est la première chose que ressentent les utilisateurs. Au cours du dernier trimestre, nous avons fait passer le démarrage à froid médian d'un service Node de 410 ms à 190 ms. Cet article présente les trois changements qui ont fait l'essentiel du travail. ## Mesurer avant de changer quoi que ce soit Nous avons découpé chaque démarrage à froid en quatre phases, chacune journalisée : planification, téléchargement de l'image, démarrage du runtime et initialisation de l'application. Le résultat nous a surpris. Les images étaient déjà en cache sur la plupart des hôtes, mais l'initialisation de l'application, le temps que votre propre code passe à importer des modules et à ouvrir des connexions, représentait presque la moitié du total. ```text title="répartition du démarrage à froid (p50, avant)" planification 38 ms image 52 ms runtime 131 ms application 189 ms total 410 ms ``` ## Prendre un instantané du runtime après le démarrage Le démarrage du runtime refait le même travail pour chaque instance d'un même build. Nous prenons désormais un instantané mémoire juste après ce démarrage, nous le stockons avec le build, puis nous le restaurons au démarrage à froid suivant. La restauration prend environ 30 ms, contre 131 ms pour un démarrage complet. Les instantanés sont pris par build : un nouveau déploiement ne restaure jamais l'état d'un ancien. ## Charger les modules à leur première utilisation Beaucoup de services importent tous leurs gestionnaires de routes au démarrage, alors qu'une requête n'en utilise qu'un seul. Le runtime prend maintenant en charge les modules de route différés : le routeur sait quel fichier gère chaque chemin, et ne l'importe qu'à la première requête sur ce chemin. ```ts title="server.ts" import { createServer } from "@cloud/runtime"; createServer({ routes: { "/api/invoices": () => import("./routes/invoices"), "/api/reports": () => import("./routes/reports"), }, }); ``` ## Envoyer la première requête à une instance déjà chaude Le dernier changement concerne le routeur. Pendant qu'une nouvelle instance démarre, la première requête part vers une instance chaude qui a de la capacité, et la nouvelle instance ne reçoit du trafic qu'une fois prête. Les utilisateurs n'attendent plus de démarrage à froid lors d'une montée en charge, seulement lors d'un départ de zéro. ## Résultats Le démarrage à froid médian est maintenant de 190 ms, et le p95 de 420 ms, contre 980 ms auparavant. Les trois changements sont actifs par défaut. Les modules de route différés nécessitent le runtime `2.4` ou plus récent. --- # Pourquoi les jetons de déploiement expirent désormais après une heure Source: https://kivo-astro.pages.dev/fr/blog/short-lived-deploy-tokens/ > Les jetons de CI à longue durée de vie sont les identifiants les plus faciles à divulguer. Voici comment fonctionnent les jetons de courte durée, et comment y passer votre pipeline en quelques minutes. Les jetons de déploiement duraient autrefois indéfiniment. On les créait une fois, on les collait dans un secret de CI, puis on les oubliait. C'est pour cela qu'ils étaient les identifiants les plus fréquents dans nos rapports d'incident : copiés dans des journaux, oubliés dans d'anciens forks ou partagés entre projets. Les nouveaux jetons de déploiement expirent désormais une heure après leur émission. Les jetons existants à longue durée de vie fonctionnent jusqu'en janvier, et le tableau de bord indique les projets qui les utilisent encore. ## Comment fonctionnent les jetons de courte durée Au lieu de stocker un jeton, votre fournisseur de CI prouve son identité avec son propre jeton d'identité (OIDC). La plateforme vérifie que cette identité correspond à une règle de confiance que vous avez créée, puis émet un jeton de déploiement valable une heure et limité à un seul projet. ```yaml title=".ci/deploy.yml" deploy: permissions: id-token: write steps: - run: npm ci - run: npx cloud deploy --env production env: CLOUD_OIDC: "true" ``` Aucun secret n'est stocké dans le dépôt ni dans les réglages de la CI. Un jeton divulgué cesse de fonctionner dans l'heure. ## Créer une règle de confiance Une règle de confiance indique quel dépôt, quelle branche et quel environnement peuvent déployer sur un projet. Créez-en une dans **Projet → Réglages → Accès au déploiement**, ou depuis la CLI : ```bash cloud trust create \ --project web-frontend \ --repository your-org/web-frontend \ --branch main \ --env production ``` Les règles sont vérifiées à chaque échange : supprimer une règle coupe l'accès immédiatement. ## Ce qui change pour vous - Les pipelines qui utilisent l'intégration CI officielle basculent automatiquement à la prochaine exécution. - Les pipelines qui appellent l'API avec un jeton stocké fonctionnent jusqu'en janvier. Ensuite, le jeton stocké est refusé. - Les jetons d'accès personnels de la CLI ne changent pas. Ils expirent toujours après 90 jours. Si votre fournisseur de CI ne prend pas encore en charge OIDC, créez un jeton avec une expiration explicite de sept jours au maximum, et renouvelez-le depuis une tâche cron. --- # Un environnement de prévisualisation pour chaque pull request Source: https://kivo-astro.pages.dev/fr/blog/preview-environments-for-every-pull-request/ > Un guide pas à pas pour déployer chaque pull request sur sa propre URL, avec sa propre branche de base de données, puis tout nettoyer à sa fermeture. Un environnement de prévisualisation est une copie complète de votre application, déployée depuis une pull request, sur sa propre URL. Les relecteurs cliquent sur un lien au lieu de récupérer la branche, et les équipes produit et design vérifient un changement avant sa fusion. Ce guide le met en place en une dizaine de minutes. ## Installer la CLI La CLI sert à lier le dépôt et à tester la configuration en local. ```bash title="npm" npm install -g @cloud/cli ``` ```bash title="pnpm" pnpm add -g @cloud/cli ``` ```bash title="yarn" yarn global add @cloud/cli ``` ```bash title="bun" bun add -g @cloud/cli ``` Connectez-vous, puis liez le projet à la racine du dépôt : ```bash cloud login cloud link --project web-frontend ``` ## Activer les prévisualisations Le fichier du projet se trouve à la racine du dépôt, à côté de `package.json` : - db/ - seed.sql - src/ - ... - **cloud.config.ts** prévisualisations et services - package.json Les prévisualisations se configurent dans le fichier du projet. Le bloc `previews` indique quelles branches en obtiennent une, quelles variables d'environnement elles utilisent, et combien de temps elles restent en ligne après la fermeture de la pull request. ```ts title="cloud.config.ts" import { defineConfig } from "@cloud/cli"; export default defineConfig({ service: "web-frontend", previews: { branches: ["*", "!main"], env: "preview", expireAfter: "3d", }, }); ``` Commitez le fichier et ouvrez une pull request. La première prévisualisation se construit aussi vite qu'un déploiement normal, et le bot publie l'URL en commentaire. **Ouvrir la prévisualisation depuis le tableau de bord** Appuyez sur ⌘ K dans le tableau de bord et tapez le numéro de la pull request pour ouvrir directement sa prévisualisation. ## Donner à chaque prévisualisation ses propres données Une prévisualisation qui écrit dans la base de staging n'est pas vraiment isolée. Ajoutez une branche de base de données pour que chaque prévisualisation parte d'une copie du schéma et d'un petit jeu de données : ```ts title="cloud.config.ts" previews: { branches: ["*", "!main"], env: "preview", database: { branchFrom: "staging", seed: "./db/seed.sql" }, }, ``` Les branches de base de données sont en copie sur écriture : en créer une prend quelques secondes, quelle que soit la taille de la base parente. ## Nettoyer Quand la pull request est fusionnée ou fermée, la prévisualisation et sa branche de base de données sont supprimées après `expireAfter`. Pour en supprimer une plus tôt : ```bash cloud previews delete --pr 142 ``` C'est tout. Désormais, chaque pull request a son lien, et rien ne reste en ligne après sa fermeture. --- # Des migrations de base de données sans interruption, en cinq étapes Source: https://kivo-astro.pages.dev/fr/blog/zero-downtime-database-migrations/ > Renommer une colonne pendant que l'application sert du trafic ne pose aucun risque si le changement est découpé en petits déploiements rétrocompatibles. Voici la méthode que nous utilisons. La plupart des pannes liées aux migrations viennent de la même erreur : le schéma et le code changent dans le même déploiement. Pendant quelques secondes, d'anciennes instances tournent sur le nouveau schéma, ou de nouvelles instances sur l'ancien, et des requêtes échouent. La solution : ne jamais laisser les deux dépendre l'un de l'autre au même moment. Prenons un exemple : renommer `users.name` en `users.full_name` sur une table très sollicitée. ## Ajouter la nouvelle colonne Ajoutez la colonne en l'autorisant à être nulle, sans valeur par défaut qui obligerait à réécrire la table. L'opération est rapide et ne bloque pas les écritures. ```sql title="migrations/001_add_full_name.sql" ALTER TABLE users ADD COLUMN full_name text; ``` ## Écrire dans les deux colonnes Déployez un code qui écrit chaque modification à la fois dans `name` et dans `full_name`, mais qui lit toujours `name`. Anciennes et nouvelles instances peuvent tourner ensemble, car les anciennes ne lisent jamais `full_name`. ## Recopier par lots Copiez les lignes existantes par petits lots, pour que la recopie ne garde jamais de verrou longtemps et ne sature pas le journal d'écriture. ```sql title="migrations/002_backfill_full_name.sql" UPDATE users SET full_name = name WHERE id IN ( SELECT id FROM users WHERE full_name IS NULL LIMIT 5000 ); ``` Exécutez-la en boucle jusqu'à ce qu'elle ne modifie plus aucune ligne. Un workflow durable s'y prête bien, car il peut se mettre en pause et reprendre entre deux lots. ## Lire la nouvelle colonne Une fois la recopie terminée et les deux colonnes identiques, déployez un code qui lit `full_name`. Continuez à écrire dans les deux colonnes pendant un déploiement de plus, pour pouvoir revenir en arrière sans perte de données. ## Supprimer l'ancienne colonne Quand plus aucune instance ne lit ni n'écrit `name`, arrêtez d'y écrire, déployez, puis supprimez-la. **Ne supprimez pas la colonne dans le même déploiement** Les instances encore en cours d'arrêt exécutent la version précédente. Si la colonne disparaît avant leur arrêt, leurs requêtes échouent. ```sql title="migrations/003_drop_name.sql" ALTER TABLE users DROP COLUMN name; ``` ## La règle derrière ces étapes Chaque déploiement doit fonctionner avec le schéma d'avant et avec celui d'après. Tant que cette règle est respectée, l'ordre des déploiements et des migrations n'a plus d'importance, et un retour arrière reste à un clic. --- # Créez des alertes de coût avant la mauvaise surprise Source: https://kivo-astro.pages.dev/fr/blog/set-cost-alerts-before-the-surprise-bill/ > Budgets, alertes par service et plafonds de dépense : un guide court pour savoir ce que vous allez payer avant que la facture n'arrive. La tarification à l'usage est juste, à condition de voir l'usage. Une tâche qui s'emballe, un cache manquant ou un pic de trafic peuvent doubler une facture en un week-end. Ce guide met en place trois niveaux de protection en un quart d'heure environ. ## Définir un budget mensuel Un budget est le montant que vous prévoyez de dépenser dans le mois. Il ne bloque rien ; il donne un point de référence à chaque alerte. Définissez-le dans **Facturation → Budget**, ou depuis la CLI : ```bash cloud billing budget set --amount 400 --currency USD ``` Le tableau de bord affiche alors votre prévision du mois à côté du budget, d'après la consommation déjà constatée. ## Alerter sur la prévision, pas sur le total Une alerte sur la dépense totale se déclenche quand l'argent est déjà parti. Une alerte sur la prévision se déclenche dès que la tendance change, souvent plusieurs jours plus tôt. ```yaml title="cloud.alerts.yml" alerts: - name: forecast-over-budget when: forecast > budget * 1.1 notify: ["#ops", "billing@example.com"] - name: daily-spike when: spend_today > spend_7d_avg * 2 notify: ["#ops"] ``` Appliquez le fichier avec `cloud alerts apply`. Une alerte peut prévenir un canal de discussion, une adresse e-mail ou un webhook. ## Trouver le service à l'origine d'un pic Quand une alerte se déclenche, ouvrez **Facturation → Consommation** et regroupez par service. Chaque service affiche son calcul, sa bande passante et son stockage du jour : un pic se résume généralement à une ligne. Les métriques du service indiquent ensuite s'il vient d'un surplus de trafic ou d'un travail plus lourd par requête. ## Plafonner ce qui peut s'emballer Certaines ressources peuvent croître sans limite : services à mise à l'échelle automatique, workers en arrière-plan et minutes de build. Fixez-leur un plafond : ```ts title="cloud.config.ts" export default defineConfig({ service: "image-worker", instances: { min: 0, max: 20 }, spendCap: { monthly: 150, action: "scale-to-min" }, }); ``` Quand le plafond est atteint, le service revient à son minimum au lieu de continuer à grandir, et l'alerte vous explique pourquoi. Relevez le plafond depuis le tableau de bord si la croissance était prévue. Avec un budget, des alertes sur la prévision et des plafonds, la facture ne fait plus que confirmer ce que vous savez déjà. --- # Les workflows durables sont disponibles pour tous Source: https://kivo-astro.pages.dev/fr/changelog/2026-10-durable-workflows/ > Exécutez des tâches en arrière-plan avec relances, délais d'expiration et journaux par étape. Les workflows découpent une tâche longue en étapes qui résistent aux redémarrages, aux déploiements et aux pannes. Chaque étape est enregistrée : en cas d'échec, seule cette étape est relancée, pas toute l'exécution. ## Ce qui est inclus - **Relances avec délai progressif** pour chaque étape, avec un nombre maximal de tentatives - **Délais d'expiration** par étape et par exécution - **Journaux par étape** dans le tableau de bord et via `cloud logs --workflow` - **Relance manuelle** depuis n'importe quelle étape en échec ## Démarrer ```ts import { workflow, step } from "@cloud/workflows"; export default workflow("send-invoices", async () => { const accounts = await step("load", () => loadAccounts()); await step("send", { retries: 5, timeout: "2m" }, () => sendAll(accounts)); }); ``` Les workflows sont facturés comme du calcul classique. Les points de reprise ne coûtent rien de plus. --- # Jetons de déploiement à courte durée par défaut Source: https://kivo-astro.pages.dev/fr/changelog/2026-09-short-lived-deploy-tokens/ > Les jetons de CI expirent désormais après une heure et sont limités à un seul projet. Les nouveaux jetons de déploiement créés depuis le tableau de bord ou la CLI expirent après une heure et ne peuvent déployer que le projet pour lequel ils ont été créés. ## Ce qui change - `cloud tokens create` émet un jeton d'une heure, sauf si vous passez `--ttl` - Les jetons sont limités à un projet et à un environnement - Les jetons longue durée existants restent valides jusqu'en **janvier 2027** ## Que faire Si votre CI stocke un jeton longue durée, passez aux jetons OIDC émis par votre fournisseur de CI, ou créez un nouveau jeton à chaque exécution : ```bash cloud tokens create --project web-frontend --env production --ttl 1h ``` --- # Des builds plus rapides grâce au cache des couches Source: https://kivo-astro.pages.dev/fr/changelog/2026-09-build-layer-caching/ > Les builds répétés sont jusqu'à trois fois plus rapides pour Node et Python. Les builds réutilisent désormais les couches de dépendances lorsque votre fichier de verrouillage n'a pas changé. La plupart des projets voient leurs builds répétés se terminer deux à trois fois plus vite. ## Détails - Fonctionne avec `package-lock.json`, `pnpm-lock.yaml`, `yarn.lock`, `poetry.lock` et `requirements.txt` - Le cache est conservé par branche : les builds de prévisualisation n'évincent pas les couches de production - Videz-le depuis **Paramètres → Build** ou avec `cloud build --no-cache` Aucune configuration n'est nécessaire. Le cache est actif sur tous les projets. --- # Le streaming des journaux ne perd plus de lignes sous charge Source: https://kivo-astro.pages.dev/fr/changelog/2026-09-log-streaming-fix/ > Les services à fort volume transmettent désormais chaque ligne au tableau de bord et à la CLI. Les services écrivant plus de 5 000 lignes par seconde pouvaient perdre des lignes en suivi en direct. Le routeur de journaux applique désormais une contre-pression au lieu de les ignorer, et la CLI reprend à la dernière ligne reçue après une reconnexion. ## Également corrigé - Les traces d'appels sur plusieurs lignes sont de nouveau regroupées en une seule entrée - `cloud logs --since` respecte le fuseau horaire défini dans votre profil --- # Réplicas en lecture pour Postgres Source: https://kivo-astro.pages.dev/fr/changelog/2026-08-postgres-read-replicas/ > Ajoutez des réplicas en un clic pour absorber les charges de lecture. Postgres managé prend désormais en charge jusqu'à cinq réplicas en lecture par base, dans la même région ou dans une autre. ## Fonctionnement - Les réplicas reçoivent les modifications du primaire avec un décalage typique inférieur à 100 ms - Chaque réplica a sa propre chaîne de connexion : `DATABASE_REPLICA_URL_1`, `_2`, etc. - Promouvez un réplica en primaire lors d'un incident régional ```bash cloud postgres replicas add orders-db --region eu-west ``` Les réplicas sont facturés au même tarif que la taille d'instance du primaire. --- # Les environnements de prévisualisation peuvent démarrer depuis un instantané de base Source: https://kivo-astro.pages.dev/fr/changelog/2026-08-preview-database-snapshots/ > Alimentez chaque pull request avec des données réalistes au lieu d'un schéma vide. Les environnements de prévisualisation peuvent désormais restaurer un instantané nocturne d'une base source au démarrage. Associez-le à un script de masquage pour garder les données personnelles hors des environnements de prévisualisation. ## Configuration ```yaml previews: database: from: orders-db snapshot: nightly mask: ./scripts/mask.sql ``` Les instantanés sont restaurés en parallèle du build : les environnements de prévisualisation ne mettent pas plus de temps à démarrer. --- # Des déploiements sans coupure plus fluides Source: https://kivo-astro.pages.dev/fr/changelog/2026-07-zero-downtime-deploys/ > Les anciennes instances terminent désormais leurs connexions ouvertes avant de s'arrêter. Les connexions longues pouvaient être coupées à l'arrêt d'une ancienne instance pendant un déploiement. Les instances quittent désormais d'abord l'équilibreur de charge, terminent les requêtes en cours pendant 30 secondes au maximum, puis s'arrêtent. Définissez une autre fenêtre de vidage par service : ```toml [deploy] drain_timeout = "60s" ``` --- # Tâches cron avec fuseaux horaires et gestion des chevauchements Source: https://kivo-astro.pages.dev/fr/changelog/2026-07-cron-timezones/ > Planifiez en heure locale et choisissez quoi faire quand une exécution est encore en cours. Les tâches cron acceptent un fuseau horaire et une règle de chevauchement. ## Options - `timezone` : n'importe quel nom IANA, par exemple `Europe/Paris`. Les changements d'heure sont gérés pour vous. - `overlap` : ignorer la nouvelle exécution (`skip`), la mettre en file (`queue`) ou remplacer celle en cours (`replace`) ```toml [[cron]] name = "nightly-report" schedule = "0 2 * * *" timezone = "Europe/Paris" overlap = "skip" ``` --- # Node 22 devient le runtime par défaut, Node 18 est obsolète Source: https://kivo-astro.pages.dev/fr/changelog/2026-06-node-22-default/ > Les nouveaux services démarrent sur Node 22. Les builds Node 18 s'arrêtent le 1er décembre 2026. Les nouveaux services Node sont désormais construits avec Node 22 LTS. Les services existants conservent leur version actuelle jusqu'à ce que vous la changiez. ## Calendrier - **Dès maintenant** : Node 22 est la version par défaut ; Node 18 affiche un avertissement dans les journaux de build - **1er décembre 2026** : les nouveaux builds sur Node 18 sont refusés - Les services en cours d'exécution ne sont jamais arrêtés Fixez une version dans `package.json` : ```json { "engines": { "node": "22.x" } } ``` --- # Exportez les journaux d'audit vers votre propre stockage Source: https://kivo-astro.pages.dev/fr/changelog/2026-06-audit-log-export/ > Transmettez chaque événement d'espace de travail et de projet vers un bucket compatible S3. Les journaux d'audit peuvent désormais être exportés en continu vers n'importe quel bucket compatible S3 qui vous appartient, pour une conservation longue ou pour votre SIEM. ## Ce qui est exporté - Connexions, création de jetons et changements de rôle - Déploiements, retours arrière et modifications des variables d'environnement - Un objet JSON par ligne, livré en moins d'une minute Activez-le dans **Paramètres de l'espace de travail → Journal d'audit → Export**. --- # Politique relative aux cookies Source: https://kivo-astro.pages.dev/fr/cookie-policy/ > Les cookies et technologies similaires utilisés par ce site web, leur rôle et la façon de les contrôler. La présente Politique relative aux cookies explique comment nous utilisons les cookies et les technologies similaires lorsque vous consultez ce site web ou que vous vous connectez au tableau de bord. Lisez-la avec notre [Politique de confidentialité](https://kivo-astro.pages.dev/fr/privacy-policy/). ## Qu'est-ce qu'un cookie Un cookie est un petit fichier texte qu'un site web enregistre dans votre navigateur. Il permet au site de mémoriser votre session, vos préférences et votre utilisation. Les technologies similaires, comme le stockage local et les pixels, fonctionnent de la même manière et sont couvertes par cette politique. ## Cookies utilisés Nous classons les cookies selon leur finalité : - **Strictement nécessaires :** maintiennent votre connexion, protègent les formulaires contre les abus et répartissent le trafic entre les régions. Le site ne fonctionne pas sans eux. - **Préférences :** mémorisent vos choix, comme la langue et le mode clair ou sombre. - **Mesure d'audience :** comptent les visites et repèrent les pages lentes, à partir de données agrégées. - **Marketing :** mesurent les inscriptions issues des campagnes. Ils restent désactivés tant que vous ne les acceptez pas. ## Détail des cookies | Cookie | Finalité | Catégorie | Durée | | ---------------- | ----------------------------------------------- | ---------------- | --------- | | `session_id` | Maintient votre connexion au tableau de bord | Nécessaire | Session | | `csrf_token` | Protège les formulaires des requêtes intersites | Nécessaire | Session | | `theme` | Enregistre votre choix de mode clair ou sombre | Préférences | 1 an | | `locale` | Enregistre votre langue | Préférences | 1 an | | `analytics_id` | Compte les visites uniques, sans votre nom | Mesure d'audience| 13 mois | | `campaign_ref` | Attribue les inscriptions à une campagne | Marketing | 90 jours | ## Cookies tiers Certaines fonctionnalités chargent des services d'autres fournisseurs, comme les vidéos intégrées, les formulaires de paiement et le chat d'assistance. Ces fournisseurs peuvent déposer leurs propres cookies, selon leurs propres politiques. Nous ne les chargeons qu'après l'ouverture de la fonctionnalité ou l'acceptation de la catégorie correspondante. ## Gérer vos préférences Vous pouvez modifier votre choix à tout moment : - Utilisez le lien des paramètres de cookies dans le pied de page pour accepter ou refuser chaque catégorie. - Bloquez ou supprimez les cookies dans les paramètres de votre navigateur. Bloquer les cookies strictement nécessaires vous déconnectera. - Activez le signal Global Privacy Control dans votre navigateur. Nous le traitons comme un refus des cookies marketing. ## Modifications de cette politique Nous pouvons mettre à jour cette politique lorsque nous ajoutons ou retirons des cookies. La date en haut de cette page indique la version en vigueur. ## Nous contacter Pour toute question sur cette Politique relative aux cookies, contactez-nous via le formulaire de contact du site. --- # Politique de confidentialité Source: https://kivo-astro.pages.dev/fr/privacy-policy/ > Comprenez comment les informations personnelles transmises via ce site web sont collectées, utilisées, protégées et gérées. Votre vie privée est importante pour nous, et nous nous engageons à protéger les informations personnelles que vous partagez avec nous. La présente Politique de confidentialité explique comment nous collectons, utilisons et protégeons vos informations lorsque vous consultez ce site web. ## Informations que nous collectons Nous collectons deux types d'informations vous concernant : - **Informations personnelles :** - Nom - Adresse e-mail - Informations de facturation (par exemple, les détails de votre carte bancaire) - Toute information que vous fournissez volontairement via des formulaires, des enquêtes ou la création d'un compte - **Informations non personnelles :** - Adresse IP - Type de navigateur - Système d'exploitation - Pages consultées et temps passé sur notre site - Site web de provenance ## Comment nous utilisons vos informations Nous utilisons les informations que nous collectons aux fins suivantes : - Fournir et améliorer nos services - Traiter les transactions et envoyer des reçus - Vous envoyer des mises à jour, des promotions et des communications liées à nos services - Personnaliser votre expérience sur notre site web - Respecter nos obligations légales - Détecter et prévenir les activités frauduleuses ## Cookies et technologies de suivi Nous utilisons des cookies et des technologies de suivi similaires pour améliorer votre expérience sur notre site web. Cela inclut : - **Cookies essentiels :** nécessaires au fonctionnement de notre site web. - **Cookies de performance :** nous aident à comprendre comment vous utilisez notre site. - **Cookies marketing :** suivent votre comportement de navigation à des fins de publicité ciblée. Vous pouvez gérer les cookies via les paramètres de votre navigateur. ## Partage des informations Nous ne vendons, ne louons ni n'échangeons vos informations personnelles. Toutefois, nous pouvons partager vos informations avec : - **Prestataires de services :** des entreprises tierces qui nous aident à exploiter notre site web et à fournir nos services. - **Autorités légales :** lorsque la loi l'exige ou pour protéger nos droits et nos biens. - **Transferts d'activité :** en cas de fusion, d'acquisition ou de cession d'actifs. ## Sécurité des données Nous mettons en œuvre des mesures de sécurité conformes aux normes du secteur pour protéger vos données. Cependant, aucune méthode de transmission sur Internet ou de stockage électronique n'est sûre à 100 %. Bien que nous nous efforcions d'utiliser des moyens commercialement acceptables pour protéger vos informations personnelles, nous ne pouvons garantir une sécurité absolue. ## Vos droits Selon votre lieu de résidence, vous pouvez disposer des droits suivants concernant vos informations personnelles : - Accéder à vos données - Corriger ou mettre à jour vos données - Demander la suppression de vos données - Limiter le traitement de vos données - Retirer votre consentement à l'utilisation de vos données Pour exercer vos droits, veuillez nous contacter via le formulaire de contact du site web. ## Liens vers des tiers Notre site web peut contenir des liens vers des sites web tiers. Nous ne sommes pas responsables des pratiques de confidentialité de ces sites web. Nous vous encourageons à consulter leurs politiques de confidentialité avant de fournir toute information personnelle. ## Confidentialité des mineurs Notre site web n'est pas destiné aux personnes de moins de 13 ans. Nous ne collectons pas sciemment d'informations personnelles auprès d'enfants de moins de 13 ans. Si vous pensez que nous avons collecté de telles informations, veuillez nous contacter immédiatement. ## Modifications de la présente Politique de confidentialité Nous pouvons mettre à jour la présente Politique de confidentialité de temps à autre. Toute modification sera publiée sur cette page avec une « Date d'entrée en vigueur » actualisée. Nous vous encourageons à consulter régulièrement la présente Politique de confidentialité. ## Nous contacter Si vous avez des questions ou des préoccupations concernant la présente Politique de confidentialité, veuillez nous contacter via le formulaire de contact du site web. Merci de nous accorder votre confiance avec vos informations personnelles. --- # Conditions générales Source: https://kivo-astro.pages.dev/fr/terms-conditions/ > Consultez les conditions qui s'appliquent lorsque les visiteurs utilisent ce site web, son contenu et ses formulaires de contact. En accédant à ce site web ou en l'utilisant, vous acceptez de respecter et d'être lié par les conditions générales suivantes (les « Conditions »). Si vous n'acceptez pas ces Conditions, veuillez ne pas utiliser ce site web. ## Acceptation des conditions En accédant au site web ou en l'utilisant, vous confirmez que vous êtes âgé d'au moins 18 ans ou que vous disposez du consentement légal d'un parent ou tuteur. Votre utilisation continue du site web constitue votre acceptation de ces Conditions. ## Utilisation du site web Vous acceptez d'utiliser le site web uniquement à des fins licites et d'une manière qui ne porte pas atteinte aux droits d'autrui ni ne restreint leur utilisation du site web. Les utilisations interdites comprennent, sans s'y limiter : - Toute activité illégale. - Toute tentative d'accès non autorisé au site web ou à ses serveurs. - L'introduction de logiciels ou de codes nuisibles, tels que des virus ou des programmes malveillants. - L'usurpation de votre identité ou de vos affiliations. ## Comptes utilisateurs Si vous créez un compte sur notre site web, vous êtes responsable du maintien de la confidentialité de vos identifiants de connexion. Vous acceptez de nous informer immédiatement de toute utilisation non autorisée de votre compte. Nous nous réservons le droit de résilier les comptes qui enfreignent ces Conditions. ## Propriété intellectuelle L'ensemble du contenu du site web, y compris, sans s'y limiter, les textes, images, logos et logiciels, est protégé par les lois sur le droit d'auteur, les marques de commerce et d'autres lois relatives à la propriété intellectuelle. Vous ne pouvez reproduire, distribuer ou modifier aucun contenu sans notre consentement écrit préalable. ## Achats et paiements Tous les achats effectués sur le site web sont soumis à nos conditions de tarification et de paiement. Vous acceptez de fournir des informations de paiement exactes et nous autorisez à débiter votre moyen de paiement des montants convenus. Les remboursements, le cas échéant, seront traités conformément à notre Politique de remboursement. ## Exclusion de garanties Le site web et son contenu sont fournis « en l'état », sans garantie d'aucune sorte, expresse ou implicite. Nous ne garantissons pas que le site web sera exempt d'erreurs, sécurisé ou disponible à tout moment. ## Limitation de responsabilité Dans toute la mesure permise par la loi, nous ne saurions être tenus responsables de tout dommage indirect, accessoire, spécial ou consécutif découlant de votre utilisation du site web ou de votre incapacité à y accéder. Notre responsabilité totale pour toute réclamation liée au site web ne dépassera pas le montant que vous nous avez versé, le cas échéant. ## Résiliation Nous nous réservons le droit de suspendre ou de résilier votre accès au site web à notre seule discrétion, sans préavis, si nous estimons que vous avez enfreint ces Conditions ou toute loi applicable. ## Liens vers des tiers Notre site web peut contenir des liens vers des sites web tiers. Nous ne sommes pas responsables du contenu ou des pratiques de ces sites web. Vous utilisez les sites tiers à vos propres risques. ## Droit applicable Les présentes Conditions sont régies et interprétées conformément aux lois de l'État d'Imaginary, aux États-Unis, sans égard à ses principes de conflit de lois. Tout litige découlant des présentes Conditions sera résolu devant les tribunaux situés à Imaginary City, aux États-Unis. ## Modifications des conditions Nous nous réservons le droit de mettre à jour ou de modifier ces Conditions à tout moment, sans préavis. Toute modification prendra effet immédiatement dès sa publication sur cette page. Votre utilisation continue du site web constitue l'acceptation des Conditions révisées. ## Nous contacter Si vous avez des questions ou des préoccupations concernant ces Conditions, veuillez nous contacter via le formulaire de contact du site web. Merci de votre visite sur ce site web.