Aller au contenu principal

Septembre 2026

Mode SaaS : plusieurs bases de données dans un projet​

Un seul projet peut désormais servir plusieurs bases de données Odoo indépendantes depuis son déploiement de production, toutes avec le même code : la configuration dont les partenaires et éditeurs ont besoin pour exploiter une solution Odoo pour de nombreux clients. Chaque base a sa propre adresse (<base>.skysize.io ou un domaine personnalisé commençant par son nom) et ses propres sauvegardes, et se crée, s'importe, se restaure ou se supprime depuis le nouvel onglet Bases de données. Un push sur la production met à jour toutes les bases ensemble, avec un retour arrière tout ou rien.

Le mode SaaS est une option d'abonnement activée par notre équipe : contactez l'équipe commerciale pour l'activer. Voir Mode SaaS.

Votre propre domaine pour chaque déploiement (BYOS)​

Les projets sur Bring Your Own Server peuvent désormais servir tous leurs déploiements sous votre propre domaine, avec un seul enregistrement DNS wildcard créé une fois pour toutes : la production, les branches de staging et les builds de développement reçoivent chacun un nom un niveau sous le domaine, et le domaine lui-même reste à vous. Les certificats sont émis automatiquement sur votre serveur, et rattacher un domaine supprime la limite de débit qui s'applique aux adresses skysize.io par défaut.

Configurez-le depuis l'onglet Paramètres du projet, section Votre domaine. Voir Votre domaine sur BYOS.

Image Docker personnalisée par serveur (BYOS)​

Vos serveurs peuvent désormais exécuter vos déploiements à partir de votre propre image Docker, dérivée de l'image Odoo officielle. C'est la solution pour ajouter des paquets apt, des bibliothèques système, des polices ou des paquets Python compilés qu'un requirements.txt ne peut pas installer. L'image se définit une fois par serveur dans Image Docker personnalisée et est utilisée dès le prochain déploiement, mise à jour ou redémarrage de chaque branche.

Les images peuvent aussi embarquer Odoo Enterprise. La documentation explique désormais précisément où placer les modules Enterprise pour qu'Odoo les trouve, avec un Dockerfile prêt à l'emploi et une commande pour vérifier le résultat.

Voir Image Docker personnalisée.

Sous-modules Git privés​

Les dépôts qui récupèrent des modules depuis des sous-modules privés se déploient désormais, sur l'hébergement managé comme sur BYOS. Chaque dépôt de sous-module privé reçoit sa propre clé de déploiement : si votre compte Git est connecté, Skysize enregistre la clé sur le dépôt du sous-module pour vous ; sinon, les paramètres du projet affichent la clé publique à ajouter vous-même.

Voir Sous-modules privés.

Migrer depuis un autre hébergeur Odoo​

Un nouveau guide détaille une migration depuis un autre hébergeur (CloudPepper, Odoo.sh, Odoo Online ou votre propre serveur) : inventaire, export d'une sauvegarde propre, répétition sur staging et bascule de la production.

Les imports sont aussi plus tolérants : les sauvegardes dont le dump SQL contient des instructions de propriété et de privilèges (OWNER TO, GRANT), comme en exportent plusieurs hébergeurs, s'importent désormais telles quelles au lieu d'échouer.

Voir Migrer depuis un autre hébergeur Odoo.

Snapshot avant mise à jour facultatif​

Avant la mise à niveau des modules, chaque mise à jour copie les bases de données du déploiement afin qu'une mise à jour ratée puisse être entièrement annulée. Sur les grosses bases, cette copie représente l'essentiel de l'interruption d'une mise à jour. Les administrateurs du projet peuvent désormais la désactiver dans les Paramètres avec Snapshot de la base avant mise à jour.

La désactivation exige d'accepter un avertissement : les mises à jour s'exécutent alors sans point de retour, et conserver une sauvegarde récente avant une mise à jour risquée devient votre responsabilité. La page des paramètres et chaque mise à jour exécutée sans snapshot indiquent qui l'a désactivé et quand.

Voir Mise à jour du build.

Des reconstructions de staging plus sûres et plus utiles​

  • Le staging exécute désormais le code de votre branche de staging. Une branche de staging reconstruite conservait le code de la production par-dessus les données de production copiées. Après la copie, la plateforme déploie maintenant la branche de staging elle-même et met à jour ses modules : le staging teste réellement votre branche sur les données de production. Si la branche ne peut pas être appliquée, le build échoue et le staging continue de servir la copie intacte.
  • Les données de staging sont neutralisées avant le démarrage d'Odoo. Les serveurs de mail sortant, les actions planifiées et les intégrations actives sont désactivés avant le tout premier démarrage du serveur de staging, et non peu après. Une copie de la production ne peut plus envoyer d'e-mails ni rafraîchir des connexions bancaires pendant ses premières secondes. Si la neutralisation échoue, le build échoue et le serveur n'est jamais démarré.

Les changements de workers s'appliquent par un redémarrage​

Modifier les workers, les workers cron ou la mémoire par worker lançait un build de mise à jour complet, avec son snapshot et la mise à niveau des modules. Ces changements redémarrent désormais simplement le déploiement de production avec les nouveaux paramètres, suivis du contrôle de santé habituel et d'un retour arrière automatique en cas d'échec.

Des règles plus claires pour les domaines personnalisés​

Un domaine personnalisé ne peut pas fonctionner tant que l'adresse de la branche passe par le proxy Cloudflare : les visiteurs obtiennent des erreurs de certificat, ou l'erreur Cloudflare 1014 si votre propre DNS est lui aussi chez Cloudflare. Le tableau de bord refuse désormais d'ajouter un domaine personnalisé dans ce cas et vous indique de désactiver d'abord le proxy. Si le DNS de votre domaine est chez Cloudflare, créez son enregistrement en DNS only.

Voir Domaines.

Premier déploiement depuis un dépôt vide​

Un projet créé sur un dépôt sans aucun commit n'affichait rien et ne déployait rien. Les onglets Builds et Branches expliquent désormais quoi faire, avec les commandes Git pour pousser un premier commit et un bouton Actualiser les branches. La première branche que vous poussez devient la branche de production et se déploie automatiquement.

Des requêtes lentes qui comptent​

La liste des requêtes lentes de l'onglet Monitoring n'affiche désormais que les requêtes réellement lentes : celles dont la durée moyenne atteint au moins 100 ms, ou dont une exécution a duré au moins 1 seconde, toujours classées par temps total. Les requêtes très rapides qu'Odoo exécute des millions de fois, ainsi que les commandes de transaction, ne masquent plus les requêtes à optimiser. Sur les serveurs BYOS, cela nécessite l'agent 1.4.1 ou plus récent.

Les déploiements en échec disent pourquoi​

Un déploiement en échec affiche désormais la raison en une phrase directement sur sa carte : un paquet Python absent du requirements.txt, un module dont les dépendances sont indisponibles, un fichier de données qui n'a pas pu être chargé (avec le fichier et la ligne), une erreur dans votre code (avec le fichier et la ligne), des tests en échec, et plus encore. Le lien Voir le journal à côté ouvre le log qui montre l'échec, déjà sélectionné.

Le message ne contient que des noms de modules, des chemins de fichiers de votre dépôt, des numéros de ligne et des types d'erreur. Il est affiché par défaut et peut être désactivé par projet dans Paramètres, Raison de l'échec sur les builds. Sur les serveurs BYOS, les raisons détaillées nécessitent la prochaine version de l'agent.

Voir Quand un déploiement échoue.

Notifications : une cloche dans le tableau de bord, et le choix du canal​

Les administrateurs d'un projet sont désormais prévenus lorsque quelque chose demande leur attention : un problème de santé en production, un déploiement de production en échec, un domaine inaccessible, un certificat sur le point d'expirer ou une mise à jour d'image Odoo planifiée. Les notifications arrivent par e-mail et sous la nouvelle cloche en haut du tableau de bord, et chacune ouvre la page concernée.

Vous choisissez les canaux dans Mon compte, Notifications : e-mail, tableau de bord, les deux (par défaut) ou aucun. Les avis de facturation sont toujours envoyés sur les deux. Les alertes de domaine sont désormais adressées aux administrateurs du projet.

Voir Notifications.

Des signaux de santé pour la production​

Skysize surveille désormais le journal Odoo et l'état du conteneur de chaque environnement de production, et transforme les problèmes connus en signaux de santé : actions planifiées en échec, coupées sur leur limite de temps ou désactivées par Odoo, workers arrêtés sur leur limite de temps ou de mémoire, conteneur qui redémarre en boucle, erreurs de requête, rafales de connexions échouées, pièces jointes manquantes, échecs d'envoi d'e-mails, et mot de passe admin par défaut toujours en place. Chaque signal indique ce qui s'est passé, combien de fois, et ce qui le corrige habituellement.

Les signaux se trouvent dans le nouvel onglet Santé. Une pastille de couleur sur l'onglet, la carte du projet et la ligne de production indique le niveau le plus grave encore ouvert, et un bandeau apparaît lorsqu'un problème est ouvert. Les signaux peuvent être pris en compte ou mis en sourdine, et un problème prévient les administrateurs du projet. Sur le Free Sandbox, la production est aussi surveillée et l'onglet indique combien de signaux sont ouverts et à quel niveau ; le détail vient avec un plan payant ou un essai.

Voir Signaux de santé de l'instance.

Copie externe automatique de vos sauvegardes​

Sur les plans payants, Skysize peut copier votre dernière sauvegarde de production dans un bucket qui vous appartient, chaque semaine, toutes les 2 semaines ou chaque mois : Amazon S3, Google Cloud Storage, Cloudflare R2 ou tout stockage compatible S3. Vous disposez ainsi d'une seconde copie de vos données hors de la plateforme, au même format .zip que Télécharger la sauvegarde. Skysize ne fait qu'écrire dans votre bucket et n'y supprime jamais rien.

Configurez-la dans Paramètres, section Copie externe, testez la connexion, puis lancez une première copie avec Copier maintenant. Voir Copie externe automatique.

Des allocations séparées pour le disque et les sauvegardes​

Chaque plan d'hébergement géré comprend désormais deux allocations distinctes : le disque (votre base de données et ses fichiers) et les sauvegardes. Une grosse base n'entame plus votre espace de sauvegarde, et inversement. L'espace supplémentaire s'ajoute par paquets pour chacune.

À 90 % d'une allocation, la page du projet affiche un avertissement avec l'utilisation et une commande prête pour l'espace supplémentaire. Au-delà de 100 %, une période de grâce commence et les administrateurs du projet sont prévenus avant toute désactivation. Un premier abonnement ou un changement de plan inclut déjà les paquets dont votre utilisation actuelle a besoin. L'offre gratuite garde sa limite unique de 5 Go.

Voir Allocations de stockage.

Odoo Enterprise depuis votre propre dépôt (BYOS)​

Les déploiements Enterprise sur votre propre serveur peuvent désormais lire le code Enterprise depuis un dépôt privé que vous contrôlez, sur n'importe quel hébergeur git, grâce à une clé de déploiement que Skysize installe pour vous. Une image Docker qui contient déjà Enterprise reste l'autre option. Lorsque vous créez un projet Enterprise sur un serveur qui n'a ni l'un ni l'autre, le formulaire vous en demande un.

Voir Exploiter BYOS.

Connecter votre premier serveur en créant un projet (BYOS)​

Plus besoin de passer d'abord par la page Agents. Lorsque vous créez un projet et choisissez Mon propre serveur, le formulaire propose l'abonnement si vous n'en avez pas encore et connecte votre premier serveur sur place. Le premier build démarre dès que le serveur est connecté.

Voir Configurer votre serveur.