TL;DR :
On a écrit un module maison pour Odoo qui prend en charge tout ce qui tourne autour d'une rencontre : ordre du jour, compte rendu, décisions, présences, et les tâches à discuter.
Les décisions prises en rencontre peuvent être reliées à notre matrice de connaissances, pour que six mois plus tard on se rappelle encore du pourquoi.
Publié sous licence libre dans notre catalogue public (github.com/bluefoxconsultant/odoo-modules), dossier bf_meeting.
Né d'un besoin simple : arrêter de disperser les traces de nos rencontres entre Word, OneNote, chaînes de courriels et post-its collés à l'écran.
Prenez une minute pour vous rappeler la dernière rencontre avec un client ou une équipe. Qui y était? Qu'est-ce qui a été décidé? Qui s'est engagé à faire quoi, pour quand?
Si la réponse est dans un document Word posé quelque part sur un OneDrive, dans un fil de courriels, ou dans la tête de la personne qui a pris les notes ce matin-là, il y a un problème. Pas tout de suite, mais dans trois mois, quand la décision sera contestée ou qu'une tâche oubliée reviendra hanter le projet.
C'est ce problème que notre module Rencontres tente de régler, sans rajouter un outil de plus dans la pile. Tout vit dans Odoo, à côté des projets, des tâches et des contacts.
Ce que ça fait, en pratique
Une rencontre a un avant, un pendant et un après. Rencontres s'occupe des trois.
Avant : on prépare l'ordre du jour dans Odoo, avec les sujets, qui présente quoi, et combien de temps ça devrait prendre. On l'envoie aux participants la veille, directement depuis l'interface, avec un PDF brandé en pièce jointe. Pas besoin d'ouvrir Word, Outlook, ni un gabarit quelque part sur un partage réseau.
Pendant : on tient le compte rendu au fur et à mesure. Les sujets abordés, les points clés, les questions ouvertes, les décisions prises et qui les a prises. Les présences sont notées (présent, absent, excusé).
Après : on envoie le compte rendu aux participants, encore une fois directement depuis Odoo, avec un PDF brandé. Les décisions prises peuvent être transférées dans la matrice de connaissances du projet, pour qu'elles survivent au temps. Les tâches discutées sont soit fermées, soit reclassées, soit placées à l'ordre du jour de la prochaine rencontre.
Le tout est rattaché au projet, à l'événement de calendrier Odoo correspondant et aux tâches concernées. On peut, depuis une tâche, voir à quelle rencontre elle sera discutée. Depuis un projet, voir l'historique des comptes rendus. Depuis un événement du calendrier, ouvrir le compte rendu en un clic.
Les tâches à discuter : l'ingrédient qu'on a mis du temps à trouver
C'est la partie qui change le plus la pratique au quotidien. On peut marquer une tâche comme « à discuter en rencontre » selon quatre modes :
- À cette rencontre précise : on l'épingle à l'ordre du jour d'une rencontre spécifique. « Je veux qu'on parle de ça à la rencontre du 15 mai. »
- À la prochaine rencontre du client : la tâche apparaîtra automatiquement au prochain ordre du jour, peu importe lequel.
- À la prochaine rencontre du projet : même logique, mais pour le prochain ordre du jour du projet concerné.
- À chaque rencontre tant que c'est pas réglé : la tâche revient à l'ordre du jour de toutes les rencontres admissibles tant qu'elle reste ouverte.
Quand on ouvre l'ordre du jour, les tâches pertinentes apparaissent toutes seules. Quand on ferme la tâche, ou quand on la transfère dans le compte rendu pendant la rencontre, elle disparaît. Pas de nettoyage manuel, pas de doublon.
Si on annule une rencontre, les tâches épinglées reçoivent un rappel pour qu'on les réassigne à la main, et les tâches marquées « prochaine rencontre » basculent d'elles-mêmes vers la suivante. Rien ne tombe entre deux chaises.
Concrètement : on peut mettre une tâche en « à discuter avec le client à la prochaine rencontre », la laisser ouverte sans y repenser, et elle apparaîtra d'elle-même à l'ordre du jour quand on planifiera la rencontre. C'est un petit détail d'ergonomie, mais c'est ce qui fait la différence entre « on en reparlera » et « c'est effectivement rediscuté ».
Quand la décision doit survivre à la rencontre
Une décision prise en rencontre ne devrait pas rester enterrée dans un PDF de compte rendu. Elle devrait remonter là où on la cherchera plus tard, par exemple dans la documentation versionnée du projet ou de l'organisation.
Notre module de matrice de connaissances sert à ça : garder les décisions organisationnelles dans un registre propre, avec historique. Rencontres se branche directement dessus. Quand on consigne une décision dans un compte rendu, on peut en un clic la transférer dans la matrice, avec le contexte de la rencontre qui l'a produite. Et depuis une ligne de matrice, on voit toutes les rencontres où elle a été discutée.
Six mois plus tard, quand quelqu'un se demande « mais pourquoi on avait choisi de faire comme ça? », la réponse est traçable jusqu'à la rencontre d'origine.
Les PDF et les courriels
On a pris soin du rendu parce que c'est ce que le client voit. Les ordres du jour et les comptes rendus sortent en PDF brandé, avec une section dédiée aux points à discuter. Les modèles de courriels d'envoi sont éditables par l'administrateur, sans toucher au code.
Installer Rencontres vaut le coup quand au moins deux de ces conditions sont réunies :
- Vos rencontres récurrentes produisent des décisions qui doivent être retrouvables dans six mois.
- Vos participants oublient régulièrement qu'une tâche devait être abordée.
- Vous tenez déjà une documentation versionnée (matrice, registre, politiques) à alimenter à partir des rencontres.
- Vous envoyez manuellement des comptes rendus par courriel après chaque rencontre, et ça vous coûte du temps.
Les limites à connaître
Le module suppose qu'une rencontre est rattachée à un projet. Pour une rencontre ponctuelle sans projet défini, il faut créer un projet conteneur, ce qui peut paraître lourd. On l'a conçu pour les organisations qui structurent déjà leur travail par projet.
Il dépend de notre module de matrice de connaissances. Les deux s'installent ensemble sans friction, mais si vous ne voulez pas de la matrice, Rencontres n'est pas l'outil qu'il vous faut.
La prise de notes pendant la rencontre se fait dans Odoo, utilisateur par utilisateur. On ne remplace pas un outil dédié à la prise de notes collaborative en temps réel, type Etherpad ou les notes collaboratives de Nextcloud. C'est un outil de structuration et d'archivage, pas de capture live à plusieurs.
Pour importer des transcriptions d'IA (Teams, Whisper, etc.), on passe par du copier-coller ou par un outil externe qui vient alimenter le compte rendu. Chez nous, on a un processeur de rencontres qui s'en charge en lot, mais il n'est pas dans le module. Qui voudrait une intégration directe devrait l'ajouter.
Enfin, il n'y a pas de support commercial officiel : le code est fourni tel quel, sous licence libre. On répond aux questions sur GitHub quand on peut, ce n'est pas un engagement contractuel.
Chez Blue Fox
On utilise Rencontres tous les jours, pour toutes nos rencontres client et nos rencontres internes. Chaque ordre du jour part par courriel la veille, avec le PDF en pièce jointe. Chaque compte rendu est envoyé après la rencontre, souvent le même jour. Les tâches discutées sont soit fermées, soit reclassées, soit transférées dans la foulée.
Pour un client qui tourne sur Odoo Community avec nous, le module est installable en une commande. On le déploie chez ceux qui ont un volume de rencontres structurées suffisant pour que l'investissement de quelques heures à se familiariser en vaille la peine. Pour les autres, on reste sur un usage plus léger du calendrier Odoo standard, sans forcer l'outil.
Le code est dans le dossier bf_meeting de notre repo public. On en avait fait le tour rapide dans notre article sur les 19 modules maison, cet article-ci est l'approfondissement.
Si vous cherchez à structurer le suivi de vos rencontres sans ajouter un outil de plus à votre stack, on jase de votre situation.
Sources
- Le module sur notre repo : github.com/bluefoxconsultant/odoo-modules, dossier
bf_meeting - Notre article catalogue : Nos 19 modules Odoo maison sont sur GitHub
- Odoo Community Association (OCA), pour l'écosystème de modules libres Odoo sur lequel on s'appuie