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.