Métiers verticaux : associations, hôtellerie, séjours, dons et accords

L'écosystème communautaire contient des verticaux métier que personne ne cherche parce qu'on ne sait pas qu'ils existent : les adhésions d'une association, la gestion d'un hôtel, les séjours d'un établissement d'accueil, les dons d'une structure d'intérêt général.

Quarante-deux modules les composent, avec les accords juridiques. Ils terminent huit dépôts.

Résumé

Douze modules traitent les adhésions : une extension du mécanisme avec ses catégories de membre, la cotisation au prorata, les périodes variables et leur combinaison, le droit d'entrée, la rétractation avec son motif et sa date, l'adhésion déléguée à un tiers avec son volet contrat, les données d'adhésion dans le CRM, et trois modules de site — badges, membres non payants, ordre aléatoire.

Sept modules traitent l'hôtellerie : un socle de gestion hôtelière avec ses étages, ses types de chambre et ses équipements, les réservations avec leur récapitulatif et leur rapport, le ménage avec ses activités, le restaurant avec ses tables et ses tickets de cuisine, deux états de réservation et de restaurant, et un gestionnaire multi-établissements.

Sept modules traitent les séjours et les dons : une gestion simple de séjours et de repas avec ses bâtiments, chambres, groupes et réfectoires, son rapport bureautique, les dons avec leurs campagnes, moyens de paiement et lettres de remerciement, leur socle, la création d'un don depuis un séjour, et la correspondance ou création d'un partenaire.

Douze modules traitent les accords : un objet accord avec ses types et son suivi d'activité, sa déclinaison juridique avec ses modèles, étapes et sous-types, ses profils de service, ses volets vente, facture, projet, réparation et assistance — avec trois colles —, et les remises contractuelles avec leurs conditions et règlements.

Quatre modules enfin traitent les exigences et les enquêtes : la gestion des exigences métier d'un client, leur priorisation par un modèle de score, le lien des enquêtes aux partenaires, et leur export en tableur.

L'essentiel

• Une cotisation au prorata et des périodes d'adhésion variables.
• La rétractation d'adhésion avec son motif et sa date.
• L'adhésion déléguée à un tiers payeur.
• Une gestion hôtelière avec chambres, ménage et restaurant.
• Des séjours et des repas avec bâtiments et réfectoires.
• Des dons avec campagnes et lettres de remerciement.
• Des accords juridiques avec modèles, étapes et profils de service.
• Des remises contractuelles avec règlements.

Ce que ces modules ajoutent à l'instance

Les menus : Membres ▸ Configuration ▸ Catégories de membre et Raisons de la rétractation, une application Hotel Management avec ses six référentiels, une application Séjours avec ses bâtiments et réfectoires, une application Don avec ses campagnes et lettres, une application Accords avec ses modèles et étapes, et une application Besoin Professionnel.

Les adhésions d'une association

Le mécanisme d'adhésion standard d'Odoo suppose une cotisation annuelle pleine, payée au début de l'année. Aucune association réelle ne fonctionne ainsi : un adhérent qui arrive en septembre paie un prorata, un couple a une cotisation familiale, et une entreprise paie l'adhésion de ses salariés.

membership_extension améliore le mécanisme et ajoute des catégories de membre. Quatre modules traitent le calcul :

• membership_prorate calcule la cotisation au prorata de la période restante.
• membership_variable_period permet des périodes d'adhésion variables, et membership_prorate_variable_period combine les deux.
• membership_initial_fee ajoute un droit d'entrée, distinct de la cotisation.

membership_withdrawal consigne la rétractation : son motif et sa date de demande, avec un référentiel de motifs.

Les motifs de rétractation sont la seule donnée qui permette à une association de comprendre pourquoi elle perd des adhérents. Sans eux, le taux de renouvellement est un chiffre sans explication.

• membership_delegated_partner permet une adhésion déléguée à un partenaire précis — l'employeur qui paie, l'adhérent qui bénéficie — avec son volet contrat.
• crm_membership affiche les données d'adhésion dans le CRM.
• Trois modules de site : des badges affichés sur le site public, l'affichage des membres non payants, et un ordre aléatoire de présentation.

Six de ces modules ont un README réduit à leur catégorie ; leur objet se lit dans leur nom.

L'hôtellerie et les séjours

hotel (LGPL-3) fournit un socle de gestion hôtelière avec son application : des étages, des types de chambre, des équipements et leurs types, et la notion de folio.

• hotel_reservation gère les réservations et leur récapitulatif, avec un rapport. report_hotel_reservation ajoute un rapport supplémentaire.
• hotel_housekeeping gère le ménage : des activités, leurs types, des services de ménage et un rapport d'activité.
• hotel_restaurant gère le restaurant : des articles alimentaires et leurs types, des tables, leur réservation, et des tickets de cuisine. report_hotel_restaurant y ajoute un état Hotel Management ▸ Reports ▸ Status By Restaurant.

multi_pms_properties (dépôt pms) fournit un gestionnaire multi-établissements — la brique d'un groupe hôtelier.

Les séjours

stay fournit une gestion simple de séjours et de repas avec son application : des bâtiments, des chambres, des groupes, des réfectoires et un ordonnancement. Il s'appuie sur une vue chronologique.

Le dépôt qui porte ce module s'appelle vertical-abbey : il a été développé pour des abbayes et des maisons d'accueil, dont le besoin n'est ni celui d'un hôtel ni celui d'un gîte — des séjours avec pension, des groupes, et des repas à compter par réfectoire.

stay_report_py3o fournit un rapport bureautique, et donation_stay permet de créer un don depuis un séjour — le modèle économique de ces établissements.

mass est un cas particulier : son README indique explicitement module vide, à désinstaller. C'est une information utile — il figure dans le dépôt et ne doit pas être installé.

Les dons

donation_base pose le socle, et donation (version 18.0.1.3.0) fournit l'application Don : des articles de don, des campagnes, des moyens de paiement et des modèles de lettre de remerciement.

La lettre de remerciement n'est pas une attention : pour un don ouvrant droit à réduction d'impôt, le reçu fiscal est une obligation, et son édition en masse après une campagne est exactement ce qu'un logiciel doit faire.

partner_match_or_create retrouve un partenaire existant ou en crée un, en s'appuyant sur la validation téléphonique. C'est la brique d'un flux de dons en ligne : un donateur récurrent ne doit pas créer un doublon à chaque don.

Les accords juridiques

agreement (version 18.0.1.3.0) fournit un objet accord avec ses types et son suivi d'activité. agreement_legal (version 18.0.1.4.1) le décline en gestion d'accords, lettres d'intention et contrats, avec ses modèles, ses étapes, ses sous-types et ses données de base.

L'accord se distingue du contrat récurrent : il porte un engagement juridique — ses clauses, ses étapes de négociation, ses signataires — là où le contrat récurrent porte une facturation. Une entreprise a besoin des deux, et ils ne se substituent pas.

• agreement_serviceprofile ajoute des profils de service avec leur tableau de bord — les engagements de niveau de service d'un accord.
• agreement_sale, agreement_account, agreement_project et agreement_repair relient l'accord aux ventes, aux factures, aux projets et aux ordres de réparation.
• agreement_helpdesk_mgmt relie un ticket d'assistance à un accord, avec trois colles vers les ventes, les interventions et les profils de service.
• agreement_rebate (version 18.0.1.2.1) gère les remises contractuelles : des conditions de remise, des règlements, leurs lignes et la création de factures.

La chaîne accord–ticket–profil de service est celle d'un prestataire sous contrat de maintenance : le ticket relève d'un accord, l'accord porte un engagement de délai, et le profil de service le définit.

agreement_rebate répond au besoin du négoce : une remise de fin d'année calculée sur le volume réalisé, avec son règlement et sa facture.

La signature d'un accord est traitée dans documents, signature et confidentialité, et les contrats récurrents dans contrats récurrents.

Les exigences métier et les enquêtes

business_requirement fournit une application de gestion des exigences métier d'un client : récits, scénarios, écarts et cas de test, avec ses catégories et ses articles.

business_requirement_rice ajoute une priorisation par modèle de score — portée, impact, confiance, effort.

C'est un module de prestataire : recenser les besoins d'un client, les chiffrer, les prioriser et les tracer jusqu'aux cas de test. Le modèle de score évite la priorisation par celui qui parle le plus fort.

• partner_survey relie les enquêtes aux partenaires : les réponses d'un client sont rattachées à sa fiche.
• survey_xlsx exporte les résultats d'enquête en tableur.

Le lien enquête-partenaire est ce qui rend une enquête de satisfaction exploitable : une réponse anonyme donne une moyenne, une réponse rattachée permet de rappeler le client mécontent.

Limites connues

• mass est un module vide à ne pas installer : son README indique explicitement « module vide, à désinstaller ».
• Onze modules ont un README réduit à leur catégorie, surtout dans le dépôt des adhésions et les colles d'accord.
• Les verticaux hôtellerie et séjours sont peu maintenus : versions en 1.0.0 ou 1.1.0, contre 1.4.x pour les modules de cœur. À évaluer avant d'y engager une activité.
• hotel est en LGPL-3 alors que ses extensions sont en AGPL-3 : à vérifier si vous distribuez du code dérivé.
• hotel_restaurant dépend du point de vente et hotel_reservation du site de vente : ces verticaux tirent plusieurs applications.
• L'accord et le contrat récurrent sont deux objets distincts : l'un porte l'engagement juridique, l'autre la facturation. Les confondre produit des doublons.
• agreement_rebate crée des factures de remise : le traitement comptable et fiscal d'une remise de fin d'année est à instruire.
• Le dépôt pms ne contient qu'un module de multi-établissements : ce n'est pas un système de gestion hôtelière complet.

Identité technique

Les quarante-deux modules viennent de huit dépôts OCA, branche 18.0 — vertical-association, vertical-hotel, vertical-abbey, donation, pms, agreement, business-requirement et survey —, désormais tous documentés ici. Quarante-et-un sont en AGPL-3, hotel est en LGPL-3. Les dépendances externes : membership, website_membership, gamification, crm, contract, account, sale_management, sale_project, sale_stock, stock, point_of_sale, website_sale, project, repair, helpdesk_mgmt, fieldservice_agreement, portal, product, survey, report_xlsx, report_py3o, web_timeline, phone_validation et account_invoice_refund_link.

Voir aussi contrats récurrents et documents, signature et confidentialité.

Questions fréquentes

Odoo gère-t-il les cotisations au prorata d'une association ?

Avec membership_prorate, oui, et membership_variable_period ajoute des périodes variables. Le mécanisme standard suppose une cotisation annuelle pleine payée en début d'année — ce qu'aucune association réelle ne pratique : un adhérent qui arrive en septembre paie un prorata.

Peut-on savoir pourquoi une association perd des adhérents ?

Avec membership_withdrawal, qui consigne le motif et la date de la demande de rétractation, avec un référentiel de motifs. C'est la seule donnée qui explique un taux de renouvellement — sans elle, c'est un chiffre sans cause.

Existe-t-il une gestion hôtelière dans l'écosystème communautaire ?

Oui : hotel et quatre modules couvrant réservations, ménage et restaurant. Mais ces verticaux sont peu maintenus — versions en 1.0.0 ou 1.1.0 contre 1.4.x pour les modules de cœur — et ils tirent plusieurs applications (point de vente, site de vente). À évaluer avant d'y engager une activité.

Quelle différence entre un accord et un contrat récurrent ?

L'accord porte un engagement juridique — clauses, étapes de négociation, signataires, profils de service — là où le contrat récurrent porte une facturation. Une entreprise a besoin des deux, et ils ne se substituent pas : les confondre produit des doublons.

Y a-t-il un module à ne pas installer dans ces dépôts ?

Oui : mass du dépôt vertical-abbey. Son README indique explicitement module vide, à désinstaller. Il figure dans le dépôt et n'a aucune fonction.

Se faire accompagner

Les verticaux communautaires sont une ressource mal connue et de maturité très inégale : les adhésions et les accords sont solides et activement maintenus, l'hôtellerie et les séjours sont des bases à reprendre. Le numéro de version en dit plus que le README.

Nous regardons donc systématiquement la maturité d'un vertical avant de le proposer — version, date du dernier correctif, nombre de dépendances — et nous préférons assembler des modules de cœur solides plutôt que d'engager une activité sur un vertical en version 1.0.0. Voir les prestations d'Atalios Consulting ou demander un rappel.

Pour aller plus loin

• Contrats récurrents, prévisions et quantités variables
• Documents, signature, confidentialité et référentiels

En résumé

L'écosystème communautaire contient des verticaux que personne ne cherche parce qu'on ne sait pas qu'ils existent : adhésions d'association, gestion d'hôtel, séjours, dons. Quarante-et-un modules les composent — de maturité très inégale, et la fiche le dit. Parlons de votre métier.