Une base de code, plusieurs instances clientes

Si vous exploitez Odoo pour plusieurs clients, la réponse habituelle est un environnement chacun : plusieurs builds, plusieurs déploiements, plusieurs choses à garder alignées. Un environnement multi-client est l'autre réponse — une base de code, une image, et une base Odoo isolée par client.

Chacune de ces bases s'appelle une instance. Votre client a ses données, ses utilisateurs et son adresse ; vous entretenez un seul environnement.

L'onglet Instances

La multi-client est un mode dans lequel un environnement est créé, et un onglet Instances apparaît sur les environnements qui l'ont. Sans lui, il n'y a rien à voir et l'onglet n'existe pas.

Les instances d'un même environnement partagent exactement ce que l'on imagine : le code, les modules et la version. Elles ne partagent rien d'autre — chacune a sa base, et Odoo choisit la bonne d'après l'adresse demandée par le navigateur.

Ce partage est tout le marché. Déployer une fois met tout le monde à jour, ce qui est l'intérêt ; cela signifie aussi qu'un mauvais déploiement atteint tout le monde, ce qui est la raison d'être du guide sur les livraisons.

Ajouter une instance

Ajouter l'instance demande un nom d'instance, un nom affiché et un e-mail d'administrateur. Le nom d'instance devient à la fois le nom de la base et le début de l'adresse : il mérite donc d'être choisi avec soin, car il ne peut plus être modifié ensuite et doit être unique sur l'environnement.

Quatre vérifications précèdent toute création, et chaque refus dit laquelle :

• l'environnement doit être multi-client et actif — on n'ajoute pas d'instance à un environnement encore en construction ;
• le compte ne doit pas être suspendu pour impayés ;
• le nom d'instance doit être libre sur cet environnement ;
• un domaine personnalisé, si vous en donnez un, ne doit pas déjà appartenir à une autre instance.

Il existe aussi une limite de longueur qui surprend : le nom d'instance et celui de l'environnement forment ensemble un nom de base PostgreSQL, qui ne peut pas dépasser 63 caractères. Un nom long ajouté à un nom d'environnement long est refusé pour cette seule raison.

La création n'est pas instantanée. La ligne apparaît aussitôt le temps que la base soit créée et Odoo initialisé, puis elle devient active toute seule. En cas d'échec, la ligne le dit et propose Réessayer, qui relance l'installation sur la base déjà créée et vous affiche un nouveau mot de passe administrateur.

Le mot de passe affiché une seule fois

À la création d'une instance, la plateforme génère le mot de passe administrateur Odoo et vous l'affiche une seule fois. Il n'est stocké sous aucune forme relisible — ni par vous, ni par le support.

Copiez-le et remettez-le à votre client tout de suite. S'il est perdu, il reste la récupération de mot de passe depuis l'Odoo du client, ou une réinstallation, qui en génère un nouveau.

Les adresses : celle qui marche toujours, et celle qu'ils veulent

Chaque instance a deux adresses. L'adresse de la plateforme dérive du nom d'instance et continue de fonctionner quoi qu'il arrive. Un domaine personnalisé est celui que votre client voudra vraiment, et l'ajouter vous donne l'enregistrement DNS que le propriétaire du domaine doit créer.

Tant que cet enregistrement n'existe pas et que le certificat n'est pas émis, c'est l'adresse de la plateforme qui fonctionne. C'est le même mécanisme que le domaine personnalisé d'un environnement : le guide correspondant s'applique ici aussi, y compris l'ordre que l'on ne peut pas inverser — le DNS d'abord, le certificat ensuite.

Suspendre, reprendre, supprimer

Suspendre met une instance hors ligne sans rien détruire : les données restent, l'adresse cesse de répondre. C'est le bon levier pour un client qui a cessé de payer, et cela se défait en un clic.

Supprimer, non. Cela détruit la base de cette instance, et l'action est protégée par sa propre permission — tenant.delete — au lieu d'être fondue dans la gestion courante. Un collaborateur peut donc exploiter vos instances clientes toute la journée sans pouvoir en effacer une.

Trois permissions se partagent le travail : tenant.view pour voir la liste, tenant.manage pour ajouter, suspendre et reprendre, et tenant.delete pour supprimer. Chacune peut être accordée sur un seul environnement plutôt que sur toute l'équipe : un collaborateur peut ainsi recevoir les instances d'un environnement et rien d'autre.

Mettre tout le monde à jour d'un coup

La raison d'exploiter ses clients ainsi, c'est qu'un seul déploiement les met tous à jour. Quand vous passez l'environnement à une nouvelle version d'Odoo, la vague de mise à jour, en haut de l'onglet, emmène chaque instance — et pas toutes en même temps.

L'ordre est ce qui compte :

1. Votre propre base d'abord. L'espace de travail de l'environnement passe avant tout client : si la nouvelle version est cassée, vous la rencontrez avant eux.
2. Puis une seule instance — le témoin. La vague s'arrête là et attend que vous regardiez.
3. Puis les autres, par lots, et uniquement dans la fenêtre de maintenance de chacune si elle en a une.

Une vague qui rencontre un échec se met en pause ; elle ne continue pas chez le reste de vos clients. Les instances déjà migrées restent où elles sont, et vous reprenez ou annulez une fois votre décision prise. Pour une opération qui touche tous vos clients, le premier échec est le moins coûteux auquel s'arrêter.