Les procédures d'une PME vivent dans trois endroits : un dossier partagé que personne n'ouvre, les courriels de la personne qui sait, et sa tête. Le troisième est le plus consulté, et il part avec elle.
document_page propose de les écrire là où le travail se fait : dans l'ERP, à côté des écrans qu'elles décrivent. Avec un historique complet, la comparaison de deux versions, et — avec le second module — une validation avant publication.
Résumé
Un wiki interne dans Odoo : pages organisées en catégories, historique complet avec comparaison de deux versions, impression en PDF, et un circuit de validation avant publication avec le second module.
Il vaut mieux qu'un dossier partagé sur un seul point, mais décisif : la proximité avec l'écran concerné — une page accessible depuis le menu où l'on travaille est lue. Et une limite sans réponse technique : un wiki non maintenu est pire qu'une absence de wiki, car une procédure périmée s'applique de bonne foi.
L'essentiel
- Un wiki interne : pages organisées en catégories, rédigées dans l'éditeur d'Odoo, imprimables en PDF.
- Historique complet de chaque page, avec comparaison de deux versions — ce qui manque à un dossier partagé.
- 89 champs, 5 menus, 2 groupes de droits pour le module central ; 37 champs et 1 menu pour l'approbation.
document_page_approval: une modification de contenu peut exiger une approbation avant de devenir la version visible.- Un menu d'accès dédié peut être généré pour une page, ce qui la place à portée de l'écran concerné.
- Menus sous Connaissances ▸ Pages.
Ce que les deux modules ajoutent à l'instance
document_page | document_page_approval | |
|---|---|---|
| Modèles créés | 2 | 0 |
| Modèles étendus | 3 | 2 |
| Champs ajoutés | 89 | 37 |
| Menus | 5 | 1 |
| Vues | 17 | 7 |
| Groupes de droits | 2 | 1 |
| Version | 18.0.2.1.3 | 18.0.1.2.0 |
| Licence | AGPL-3 | AGPL-3 |
89 champs pour un wiki : l'essentiel vient de l'historique de versions, qui stocke chaque état successif du contenu. C'est aussi ce qui en fait un module à surveiller côté volume si vos pages sont longues et modifiées souvent.
Le module dépend de document_knowledge, mail et web_editor — ce dernier étant l'éditeur de contenu riche d'Odoo, le même que celui des modèles de courriel.
Où le trouver dans Odoo
| Menu | Ce qu'on y fait |
|---|---|
| Connaissances ▸ Pages | Le menu racine du wiki |
| … ▸ Pages | La liste des pages |
| … ▸ Catégories | L'organisation en catégories |
| … ▸ Historique des pages | Toutes les versions, toutes pages confondues |
| … ▸ Demandes de modification | Les validations en attente (module d'approbation) |
| Connaissances ▸ Parcourir le contenu du wiki | La navigation en lecture |
La dernière entrée est celle qu'il faut montrer aux utilisateurs : les autres sont des écrans de gestion. Et une page peut recevoir son propre menu d'accès, ce qui permet de la placer à côté de la fonction qu'elle documente plutôt que dans une arborescence de documentation.
Cas d'usage
Écrire une procédure et l'organiser
- Connaissances ▸ Pages ▸ Catégories : créer la catégorie — par exemple « Comptabilité », « Atelier », « Accueil client ».
- Connaissances ▸ Pages ▸ Pages, puis Nouveau : titre, catégorie, et contenu rédigé dans l'éditeur.
- Enregistrer : la page est consultable, imprimable en PDF, et chaque modification ultérieure est historisée.
Comparer deux versions d'une procédure
C'est la fonction qui distingue ce module d'un dossier partagé, et celle qui sert le plus lors d'un contrôle qualité ou d'un désaccord sur « ce qui était écrit avant ».
- Ouvrir la page concernée.
- Accéder à son historique : chaque modification y figure, avec son auteur et sa date.
- Sélectionner deux versions et les comparer.
Exiger une validation avant publication
Avec document_page_approval, toute modification du contenu peut nécessiter une approbation avant de devenir la version visible par les lecteurs. C'est la différence essentielle : la page publiée reste l'ancienne jusqu'à validation.
- Installer
document_page_approval. - Configurer l'exigence d'approbation au niveau de la catégorie concernée.
- Un rédacteur modifie une page : sa modification part en demande de modification.
- Un responsable la retrouve dans Connaissances ▸ Pages ▸ Demandes de modification, la relit, l'approuve ou la refuse.
L'usage pour lequel ce module existe : les procédures dont une version erronée a des conséquences — une consigne de sécurité, une règle de facturation, un protocole sanitaire. Dans ces cas, publier sans relecture est le vrai risque.
Pourquoi la documentation gagne à vivre dans l'ERP
L'argument n'est pas technique, et il vaut d'être posé parce que la plupart des entreprises ont déjà un dossier partagé.
| Dossier partagé | Wiki dans l'ERP | |
|---|---|---|
| Distance à l'écran concerné | Un autre outil, un autre onglet | Le même outil, parfois le même menu |
| Historique des modifications | Des fichiers « v3_final » | Versionné, avec comparaison |
| Qui a écrit quoi | Les métadonnées du fichier, parfois | Auteur et date par version |
| Validation avant publication | Par convention | Par circuit, avec le module d'approbation |
| Droits de lecture | Ceux du dossier | Ceux d'Odoo, par groupe |
La première ligne est la seule qui change réellement l'usage : une procédure accessible depuis le menu où l'on travaille est lue ; la même procédure dans un dossier partagé ne l'est pas. C'est ce que permet le menu d'accès dédié à une page.
C'est aussi le raisonnement que nous appliquons à notre propre documentation : 1 725 fiches de modules, une par module, consultables là où la question se pose. Voir un assistant qui répond sur vos propres documents.
Les trois pages qui servent vraiment
Un wiki d'entreprise se remplit vite et se lit peu. D'après ce que nous observons, trois types de pages sont consultés et les autres non.
- « Comment on fait X ici » — la procédure d'un geste précis, avec les noms d'écrans réels : saisir une facture fournisseur, créer un devis avec remise, clôturer un mois. C'est ce que cherche quelqu'un qui est bloqué maintenant.
- Les décisions de paramétrage et leur raison. Pourquoi la valorisation du stock est en coût moyen, pourquoi tel journal a telle séquence, pourquoi ce contrôle est bloquant. Ces pages valent de l'or dans trois ans, quand personne ne se souvient de la raison.
- Les cas particuliers de clients ou de fournisseurs. « Ce client exige un code de routage », « ce fournisseur facture en fin de mois ». C'est la connaissance qui part avec les gens.
Ce qui ne se lit pas : les pages de présentation générale, les organigrammes, et tout ce qui décrit l'entreprise plutôt que le travail.
La deuxième catégorie est celle que nous recommandons le plus fortement, parce qu'elle répond au problème que nous documentons ailleurs : un développement ou un rapport SQL dont personne ne sait plus pourquoi il existe. Voir personnaliser ou rester sur le standard.
Limites connues
Les dépôts ne répertorient pas de défaut sur ces deux modules. Quatre limites d'usage, en revanche, déterminent s'ils vous conviennent.
- Ce n'est pas un outil de rédaction collaborative en temps réel. On modifie une page, on l'enregistre : il n'y a pas d'édition simultanée à plusieurs.
- L'historique fait du volume. Chaque version stocke son contenu : sur des pages longues et souvent modifiées, c'est un poste à surveiller dans la taille de la base.
- L'approbation se configure par catégorie, pas page par page : il faut organiser ses catégories en fonction du niveau de contrôle souhaité, pas seulement du sujet.
- Un wiki non maintenu est pire qu'une absence de wiki. Une procédure périmée que l'on applique de bonne foi cause plus de dégâts qu'une procédure absente, où l'on demande.
La dernière est la seule qui compte vraiment, et elle n'a pas de réponse technique : il faut désigner qui relit, et à quelle fréquence. Une page sans date de dernière revue est une page dont personne ne sait si elle est à jour.
Le module d'approbation aide précisément là : il fournit la trace de qui a validé quoi, et quand.
Identité technique
| Module | Dépôt OCA | Version | Licence | Dépend de |
|---|---|---|---|---|
document_page | knowledge | 18.0.2.1.3 | AGPL-3 | document_knowledge, mail, web_editor |
document_page_approval | knowledge | 18.0.1.2.0 | AGPL-3 | document_page, mail |
Le dépôt knowledge compte 15 modules documentés, dont document_page_access_group qui ajoute une gestion des droits de lecture par groupe. Les deux ci-dessus font partie de notre socle commun.
Questions fréquentes
En quoi un wiki dans Odoo vaut-il mieux qu'un dossier partagé ?
Sur un seul point, mais il est décisif : la proximité avec l'écran concerné. Une page accessible depuis le menu où l'on travaille est lue ; la même page dans un dossier partagé ne l'est pas. S'y ajoutent l'historique versionné avec comparaison, l'auteur par version, et des droits de lecture gérés par les groupes Odoo.
Peut-on comparer deux versions d'une procédure ?
Oui, c'est l'une des fonctions principales : chaque modification est historisée avec son auteur et sa date, et l'on peut sélectionner deux versions pour les comparer. C'est ce qui sert lors d'un contrôle qualité ou d'un désaccord sur « ce qui était écrit avant ».
Comment exiger une relecture avant publication ?
Avec document_page_approval : une modification de contenu part en demande de modification, et la version visible par les lecteurs reste l'ancienne jusqu'à validation. L'exigence se configure au niveau de la catégorie, pas page par page — organisez vos catégories en conséquence.
Quelles pages faut-il écrire en premier ?
Trois types se lisent, les autres non : « comment on fait X ici » avec les noms d'écrans réels, les décisions de paramétrage et leur raison, et les cas particuliers de clients ou fournisseurs. La deuxième catégorie est la plus précieuse à long terme : elle évite qu'un réglage devienne inexplicable.
Plusieurs personnes peuvent-elles rédiger en même temps ?
Non, ce n'est pas un outil d'édition collaborative en temps réel : on modifie une page et on l'enregistre. Pour une rédaction à plusieurs mains sur un même document, il faut un autre outil — et importer le résultat ici une fois stabilisé.
Se faire accompagner
Le module s'installe en une minute ; ce qui ne s'installe pas, c'est la décision de qui écrit, qui relit et à quelle fréquence. Un wiki non maintenu est pire qu'une absence de wiki : une procédure périmée appliquée de bonne foi cause plus de dégâts qu'une procédure absente.
Nous écrivons avec vous les pages qui comptent — les décisions de paramétrage et leur raison, en premier — et nous mettons en place le circuit d'approbation sur les catégories qui le méritent. C'est une part de notre formation des équipes, et ce qui rend une instance autonome. Demander un rappel.
Pour aller plus loin
- Faire adopter Odoo par ses équipes : ce qui marche vraiment
- Un assistant qui répond sur vos propres documents
- Le socle commun : les 57 modules de chaque instance
En résumé
Un wiki dans l'ERP vaut un dossier partagé sur un point décisif : la proximité avec l'écran concerné. S'y ajoutent l'historique versionné avec comparaison, et un circuit d'approbation par catégorie. Écrivez d'abord les décisions de paramétrage et leur raison — c'est ce qui vaut le plus dans trois ans. Parlons de votre documentation interne.
