OdooAsso Gestion du projet Mise en place OdooAsso — Projet de modules Odoo pour la gestion associative Contexte Odoo présente une orientation naturelle vers l'entreprise et un niveau de complexité d'usage trop important pour les utilisateurs d'associations. L'objectif de ce projet est de regrouper tous les besoins en quelques modules cohérents pour simplifier au maximum la gestion, et de produire un travail de qualité suffisante pour être partagé avec d'autres associations. Stack cible : Odoo 16 Community, déployé en Docker. Modules tiers utilisés : modules OCA (vertical association, membership, partner…), modules Deodoo. Architecture du dépôt Structure monorepo inspirée du standard OCA : OdooAsso/ # dépôt public GitHub/GitLab ├── README.md ├── projet.md ├── .pre-commit-config.yaml # linting OCA ├── setup.cfg ├── oca_dependencies.txt # versions des modules OCA requis ├── asso_base/ # socle — groupes, menus racine, mixins ├── asso_membership/ # gestion des membres et cotisations ├── asso_event/ # événements et activités ├── asso_accounting/ # comptabilité simplifiée (loi 1901) ├── asso_portal/ # portail adhérent └── asso_website/ # front public Principe de séparation asso_base déclare les groupes d'accès, les menus racine et les mixins réutilisables. Tous les autres modules en dépendent. Les modules métier sont indépendants les uns des autres autant que possible, pour permettre une adoption partielle. Namespace Le préfixe asso_ est choisi pour être neutre et réutilisable (pas de nom d'association spécifique). Si le projet vise explicitement le contexte français (loi 1901, plan comptable associatif), le préfixe fr_asso_ peut être envisagé. Stratégie de simplification UX C'est le cœur de la valeur ajoutée du projet. Odoo est simplifié à trois niveaux : 1. Groupes d'accès dédiés Des groupes propres sont créés, sans réutiliser les groupes Odoo natifs : group_asso_user — membre du bureau, usage courant group_asso_manager — responsable, accès étendu group_asso_admin — administrateur technique Cela permet de masquer tout ce qui n'est pas pertinent pour une association. 2. Menus simplifiés Les menus natifs Odoo sont désactivés ( active="False" ) pour les groupes asso_* Une arborescence plate et orientée tâches les remplace : Membres → Activités → Finances → Communication 3. Vues allégées Les vues natives sont héritées pour masquer les champs inutiles L'attribut groups est utilisé sur les champs avancés (visibles admins seulement) 4. Wizards pour les actions courantes Les opérations fréquentes sont regroupées en wizards pour éviter la navigation multi-menus : inscription en masse, relances cotisations, exports, etc. Qualité et partageabilité Outils Outil Rôle pre-commit (config OCA) Linting XML, Python, manifest Tests unitaires Odoo Validation des modèles et flux métier oca_dependencies.txt Déclaration explicite des dépendances OCA Lancer les tests odoo-bin --test-enable --stop-after-init -i asso_membership Conventions Chaque module déclare ses dépendances OCA explicitement dans son __manifest__.py Les données de configuration ( data/ ) sont séparées des données de démonstration ( demo/ ) Les champs custom sont préfixés avec le nom du module ( membership_date_end plutôt que x_date_end ) Environnement de développement Le projet tourne en Docker. Ajouter un docker-compose.override.yml pour monter le dépôt directement dans le addons_path : services: odoo: volumes: - ./OdooAsso:/mnt/extra-addons Travailler en mode --dev xml pour recharger les vues sans redémarrer le serveur. Modules — périmètre fonctionnel asso_base Groupes d'accès et règles de sécurité Menus racine et structure de navigation Modèles abstraits et mixins partagés Configuration générale de l'association asso_membership Gestion des adhérents (hérite res.partner ) Types d'adhésion et tarifs Suivi des cotisations et renouvellements Relances automatiques asso_event Événements et activités de l'association Inscriptions et présences Lien avec les adhérents asso_accounting Simplification de la comptabilité pour le contexte associatif (loi 1901) Plan comptable associatif Suivi des subventions asso_portal Espace adhérent en ligne Consultation et renouvellement d'adhésion Inscription aux événements asso_website Pages publiques de l'association Formulaire d'adhésion en ligne Agenda public des événements Étapes de démarrage Initialiser le dépôt Git avec la structure monorepo Configurer pre-commit avec la config OCA standard Lister les fonctionnalités par module en partant des douleurs utilisateurs actuelles Créer asso_base : groupes, menus racine, modèles abstraits Migrer progressivement les développements existants dans cette structure Analyse Voici une méthode simple, efficace et adaptée au monde associatif pour structurer votre phase d’analyse et rédiger un cahier des charges léger, sans alourdir le processus. L’idée est de rester pragmatique et centré sur l’essentiel, tout en préparant le terrain pour un développement modulaire et réutilisable. 1. Phase d’Analyse : 4 Étapes Clés Étape 1 : Identifier les Parties Prenantes Objectif : Savoir qui va utiliser le système et quels sont leurs besoins réels. Actions : Lister les rôles dans l’association (ex : trésorier, secrétaire, bénévole événementiel, membre). Pour chaque rôle, noter : 3 tâches principales qu’ils doivent accomplir avec Odoo. 3 frustrations actuelles avec l’outil (ex : "trop de champs inutiles", "je ne trouve pas où renouveler une adhésion"). Exemple de tableau synthétique : Parties prenantes et besoins Rôle Tâches Principales Frustrations Actuelles Trésorier Suivre les cotisations, générer des rapports Trop de menus comptables inutiles Secrétaire Gérer les membres, envoyer des emails Pas de vue d’ensemble des adhésions Bénévole Événement Inscrire des participants, envoyer des infos Processus d’inscription trop long Étape 2 : Cartographier les Processus Clés Objectif : Visualiser les workflows actuels pour identifier les simplifications possibles. Méthode : Pour chaque tâche principale, dessiner un parcours utilisateur simplifié (3 à 5 étapes max). Exemple pour "Renouveler une adhésion" : Le membre reçoit un email de rappel. Il clique sur un lien vers Odoo. Il voit un formulaire pré-rempli avec ses infos. Il paie en ligne (ou valide un virement). L’adhésion est mise à jour automatiquement. Outils : Un tableau blanc (Miro, Draw.io) ou même un papier pour schématiser. Astuce : Filmer un utilisateur qui effectue la tâche actuelle pour repérer les points de friction. Étape 3 : Prioriser avec la Matrice "Impact/Effort" Objectif : Concentrer les efforts sur ce qui apporte le plus de valeur avec le moins de complexité. Méthode : Lister toutes les fonctionnalités souhaitées. Les classer dans un tableau à 4 cases : Matrice Impact/Effort   Effort Faible Effort Élevé Impact Élevé À faire en priorité À planifier (phase 2) Impact Faible Optionnel À éviter Exemple : Priorité haute : Simplifier le renouvellement des adhésions (impact élevé, effort faible si on utilise un wizard). Phase 2 : Intégrer un système de paiement en ligne (impact élevé, mais effort technique important). Optionnel : Ajouter un champ "allergies" pour les événements (impact faible). Étape 4 : Rédiger un Cahier des Charges Léger Structure proposée (1 à 2 pages max) : Contexte : "Notre association utilise Odoo 16, mais l’outil est trop complexe pour nos bénévoles. Nous souhaitons simplifier l’interface et regrouper les fonctionnalités essentielles dans des modules dédiés." Objectifs : "Réduire de 50% le nombre de clics pour les tâches quotidiennes (ex : renouvellement d’adhésion)." "Masquer les fonctionnalités non utilisées (ex : comptabilité analytique)." "Permettre à d’autres associations de réutiliser nos modules." Périmètre : Modules à développer (liste priorisée) : Gestion des membres (adhésions, profils). Gestion des événements (inscriptions, participations). Tableau de bord simplifié pour le trésorier. Hors périmètre : "La gestion des stocks (non utilisée par l’association)." Exigences Fonctionnelles : "Un bouton 'Renouveler' visible sur la fiche membre, déclenchant un wizard en 3 étapes." "Une vue liste des membres avec filtres par statut (actif/inactif/retard)." Exigences Techniques : "Compatibilité avec Odoo 16 et les modules OCA/Deodoo existants." "Code documenté et publié sur GitHub sous licence MIT." Livrables : "Modules Odoo prêts à installer (avec README et guide utilisateur)." "Formation vidéo de 10 min pour les bénévoles." 2. Outils pour Aller Vite Pour les schémas : Draw.io (gratuit, export en PNG/PDF). Pour la priorisation : Un tableau Trello ou GitHub Projects. Pour le cahier des charges : Un Google Doc partagé ou un fichier Markdown dans le repo GitHub. 3. Exemple Concret : Module "Gestion des Membres" Besoin : "Simplifier le renouvellement des adhésions." Analyse : Processus actuel : 7 clics, passage par 3 menus différents. Processus cible : 3 clics via un wizard. Spécifications : Bouton "Renouveler" sur la fiche membre → Ouvre un formulaire avec : Montant de la cotisation (pré-rempli). Méthode de paiement (virement ou CB). Case à cocher pour accepter le règlement intérieur. À la validation : envoi automatique d’un email de confirmation + mise à jour du statut. 4. Prochaines Actions Valider la liste des parties prenantes avec 2-3 membres de l’association. Choisir 1 processus clé (ex : renouvellement d’adhésion) et le cartographier ensemble. Remplir la matrice Impact/Effort pour prioriser. Question pour vous, Nicolas : Souhaitez-vous commencer par affiner la liste des parties prenantes et leurs besoins, ou préférez-vous cartographier directement un processus type (ex : gestion des événements) ? Je peux vous fournir un template prêt à l’emploi pour l’un ou l’autre.