Documents, signature, confidentialité, tableurs et référentiels européens

Quatre besoins transverses n'ont pas de réponse dans Odoo Community : classer des documents avec des droits, faire signer un contrat sans service tiers, tenir le registre des traitements exigé par le règlement européen, et disposer des référentiels normalisés qu'exige le commerce international.

Trente-et-un modules communautaires y répondent, et terminent six dépôts.

Résumé

Sept modules traitent la gestion documentaire : un système de documents avec ses catégories, ses étiquettes, ses accès par groupe et son portail, des vues documentaires intégrées dans un enregistrement, le classement automatique avec sa variante intégrée, les rôles utilisateur, un volet ressources humaines, et l'intégration à la fenêtre de médias de l'éditeur.

Trois modules traitent la signature électronique : la signature dans Odoo, son application aux tâches de projet et aux accords juridiques.

Quatre modules traitent la confidentialité : un registre des traitements avec ses activités, ses partenaires et ses rapports, la gestion du consentement explicite, l'anonymisation d'un partenaire au titre du droit à l'oubli, et l'anonymisation de champs à l'export pour certains groupes.

Cinq modules traitent les tableurs : un moteur de tableurs éditables avec ses étiquettes, son usage dans les tableaux de bord, deux tableaux de bord prêts pour les achats et les achats-stock, et des tableurs comme calculateurs de devis liés aux modèles de commande.

Trois modules traitent le moteur de recherche : un connecteur générique avec ses index, une implémentation concrète, et un sérialiseur.

Neuf modules enfin fournissent les référentiels : les codes UNECE pour les taxes, les paiements et les unités, les codes ISO 3166, la banque déduite d'un IBAN, la classification européenne NACE, les marchandises dangereuses ADR avec son complément, les allergènes, les zones de pêche, et le registre sanitaire.

L'essentiel

• Un système documentaire avec droits par groupe et portail.
• Des vues documentaires intégrées dans un enregistrement.
• La signature électronique dans Odoo, sans service tiers.
• Un registre des traitements et la gestion du consentement.
• L'anonymisation de champs à l'export pour certains groupes.
• Des tableurs éditables et des calculateurs de devis.
• Les codes UNECE : taxes, paiements, unités de mesure.
• Les marchandises dangereuses ADR et les allergènes.

Ce que ces modules ajoutent à l'instance

Les menus : une application Documents avec ses catégories, étiquettes et accès par groupe ; une application Signature avec ses modèles, champs et rôles ; une application Privacy avec ses activités et ses rapports ; une application Tableurs ; une application Moteur de recherche ; Paramètres ▸ Technique ▸ Paramètres ▸ Listes de codes UNECE ; Inventaire ▸ Configuration ▸ Marchandises dangereuses et ses quatre référentiels.

La gestion documentaire

dms (LGPL-3, version 18.0.1.2.1) fournit un système de gestion documentaire : répertoires, catégories, étiquettes, accès par groupe, et un accès portail — donc partageable avec un client ou un fournisseur.

dms_field (LGPL-3, version 18.0.1.2.3) crée des vues documentaires intégrées dans un enregistrement, avec des gabarits. C'est le module qui change l'usage : les documents d'un dossier client apparaissent dans sa fiche.

La différence entre une gestion documentaire et un dossier partagé tient aux droits et au rattachement : les documents d'un contrat sont visibles de qui voit le contrat, et ils apparaissent dans sa fiche. Un dossier partagé ne sait faire ni l'un ni l'autre.

• dms_auto_classification et dms_field_auto_classification assurent le classement automatique des documents.
• dms_user_role relie les droits documentaires aux rôles utilisateur.
• hr_dms_field apporte un volet ressources humaines — le dossier d'un salarié.
• web_editor_media_dialog_dms intègre les documents à la fenêtre de médias de l'éditeur : insérer une image gérée dans un contenu.

Le wiki interne et ses pages sont traités dans la base de connaissance — deux approches distinctes : la page rédigée et le document classé.

La signature électronique

sign_oca (version 18.0.1.4.3) permet de signer des documents dans Odoo Community, avec une application dédiée : des modèles de document à signer, des champs à placer, des rôles de signataire et des demandes de signature.

Signer dans Odoo plutôt que par un service tiers change deux choses : le document signé reste dans l'ERP, rattaché à son contrat ou sa commande ; et aucune donnée ne part chez un prestataire. En contrepartie, la valeur probante d'une signature dépend du dispositif retenu, non du logiciel.

• project_task_sign_oca applique la signature aux tâches de projet — une réception de travaux, un bon d'intervention.
• agreement_sign_oca l'applique aux accords juridiques.

La mise en garde est importante : un module de signature produit une signature. Son niveau juridique — simple, avancée, qualifiée au sens du règlement européen — dépend du procédé d'identification et d'horodatage mis en place, qui est une question de dispositif et non de module.

La confidentialité et le registre des traitements

privacy fournit une application Privacy : un registre des activités de traitement, les partenaires concernés, des rapports et des réglages — ce que le règlement européen exige de documenter.

Le registre des traitements est le premier document qu'une autorité de contrôle demande, et celui que presque aucune PME n'a. Le tenir dans l'ERP plutôt que dans un tableur a un avantage décisif : il se rattache aux données réelles, et il se met à jour quand elles changent.

• privacy_consent permet aux personnes d'accepter ou de refuser explicitement leur inclusion dans une activité de traitement, avec son référentiel de consentements.
• privacy_partner_to_be_forgotten (LGPL-3) anonymise les données d'un partenaire au titre du droit à l'oubli.
• base_export_anonymize anonymise certains champs à l'export pour un groupe d'utilisateurs — directement ou par les champs relationnels.

L'anonymisation à l'export est la pièce que l'on n'attend pas et qui compte : un export autorisé pour une analyse n'a pas besoin des noms et des adresses, et ce module permet de les retirer sans retirer le droit d'exporter.

Les droits d'export eux-mêmes sont traités dans paramétrer sans développer.

Les tableurs et le moteur de recherche

spreadsheet_oca (version 18.0.1.3.2) permet d'éditer des tableurs dans Odoo, avec une application Tableurs et ses étiquettes.

• spreadsheet_dashboard_oca permet d'utiliser ces tableurs dans la configuration des tableaux de bord.
• spreadsheet_dashboard_purchase_oca et spreadsheet_dashboard_purchase_stock_oca (LGPL-3) fournissent deux tableaux de bord prêts pour les achats et les achats liés au stock.
• spreadsheet_quotation permet d'utiliser des tableurs comme calculateurs de devis, liés aux modèles de commande de vente.

Le calculateur de devis par tableur répond à un besoin très réel du sur-mesure : un chiffrage qui dépend de dimensions, de coefficients et de barèmes vit naturellement dans un tableur. Le relier au modèle de commande évite de ressaisir le résultat.

Trois modules traitent le moteur de recherche : connector_search_engine fournit le cadre avec ses index et ses backends, connector_typesense une implémentation concrète, et search_engine_serializer_pydantic un sérialiseur.

C'est la brique dont dépendent les modules d'export de catalogue par canal de vente : un moteur de recherche externe sert un catalogue en ligne plus vite qu'une requête en base.

Les référentiels européens et sectoriels

Quatre modules fournissent les codes UNECE — les nomenclatures normalisées par la Commission économique pour l'Europe : un socle avec ses listes de codes, et leur application aux taxes, aux moyens de paiement et aux unités de mesure.

Ces trois codifications sont obligatoires dans une facture électronique conforme à la norme européenne. Ce sont les modules dont dépend tout le socle de facturation électronique — et leur absence produit un fichier rejeté sans explication lisible.

• base_iso3166 enrichit la fiche pays des codes ISO 3166-1 alpha-3 et numériques.
• base_bank_from_iban déduit la banque d'un IBAN saisi.
• l10n_eu_nace importe la classification européenne NACE des activités économiques.

Les référentiels sectoriels

• l10n_eu_product_adr (version 18.0.1.1.0) permet de marquer des articles comme dangereux et de leur associer les informations réglementaires, avec quatre référentiels — classes, étiquettes, instructions d'emballage, marchandises. l10n_eu_product_adr_dangerous_goods le complète.
• product_allergen gère les allergènes sur les produits, avec affichage d'icônes.
• product_fao_fishing qualifie un produit selon les zones de pêche — obligation d'étiquetage des produits de la mer.
• company_sanitary_registry enregistre le numéro d'agrément sanitaire — l'agrément européen de l'agroalimentaire —, par catégorie et par entrepôt.

Ces quatre modules répondent à des obligations d'étiquetage et de déclaration précises, propres à l'agroalimentaire, aux produits de la mer et au transport de matières réglementées.

Les marchandises dangereuses au transport sont traitées dans expédier au quotidien.

Limites connues

• Six modules ont un README réduit à leur catégorie : trois modules documentaires, deux modules de signature et deux tableaux de bord.
• Un module de signature produit une signature : son niveau juridique — simple, avancée, qualifiée — dépend du procédé d'identification et d'horodatage retenu, pas du module.
• Le registre des traitements est un document à tenir : le module fournit le cadre, le contenu reste à écrire et à maintenir.
• L'anonymisation au titre du droit à l'oubli est irréversible : c'est son objet, et il faut en connaître la portée avant de l'exécuter.
• L'anonymisation à l'export protège l'export, pas la base : un utilisateur ayant accès aux écrans voit les données.
• connector_search_engine dépend de quatre modules dont les travaux de fond et l'environnement serveur : un moteur de recherche externe est un service de plus à exploiter.
• dms dépend de six modules dont le portail et le routage : c'est une application, pas un ajout de champ.
• Les référentiels sectoriels supposent un travail de classification produit : marquer les allergènes ou les matières ADR article par article est un chantier.

Identité technique

Les trente-et-un modules viennent de six dépôts OCA, branche 18.0 — dms, sign, data-protection, spreadsheet, search-engine et community-data-files —, désormais tous documentés ici. Vingt-cinq sont en AGPL-3, six en LGPL-3. Les dépendances externes : portal, http_routing, web_editor, base_sparse_field, bus, spreadsheet, spreadsheet_dashboard, base_user_role, agreement_legal, project, pydantic, queue_job, server_environment, base_partition, base_iban, base_unece, partner_industry_secondary et product_attribute_value_avoid_auto_fill.

Voir aussi la base de connaissance et UBL, Factur-X et l'envoi des factures.

Questions fréquentes

Peut-on faire signer un document dans Odoo Community ?

Oui, avec sign_oca : une application de signature avec modèles, champs, rôles de signataire et demandes. Le document signé reste dans l'ERP et aucune donnée ne part chez un prestataire. Attention : le niveau juridique de la signature — simple, avancée, qualifiée — dépend du procédé d'identification et d'horodatage, pas du module.

Quelle différence entre dms et une gestion de fichiers partagés ?

Les droits et le rattachement : avec dms et dms_field, les documents d'un contrat sont visibles de qui voit le contrat, et ils apparaissent dans sa fiche. Un dossier partagé ne sait faire ni l'un ni l'autre. Le module apporte aussi un accès portail, donc partageable avec un client.

Odoo peut-il tenir le registre des traitements RGPD ?

Oui, avec privacy : un registre des activités de traitement avec les partenaires concernés et des rapports. C'est le premier document qu'une autorité de contrôle demande, et celui que presque aucune PME n'a. Le tenir dans l'ERP a un avantage : il se rattache aux données réelles. Le contenu reste à écrire.

Peut-on autoriser un export sans donner les noms et adresses ?

Oui : base_export_anonymize anonymise certains champs à l'export pour un groupe d'utilisateurs, y compris par les champs relationnels. Un export autorisé pour une analyse n'a pas besoin des données nominatives — et ce module les retire sans retirer le droit d'exporter.

À quoi servent les codes UNECE ?

Les trois codifications — taxes, moyens de paiement, unités de mesure — sont obligatoires dans une facture électronique conforme à la norme européenne. Ce sont les modules dont dépend tout le socle de facturation électronique, et leur absence produit un fichier rejeté sans explication lisible.

Se faire accompagner

Ces quatre sujets reviennent dans presque tous les projets, et aucun n'est jamais inscrit au cahier des charges initial : où vont les documents, comment on fait signer, qui tient le registre RGPD, et quels référentiels normalisés il faut installer avant de parler de facturation électronique.

Nous traitons donc les codes UNECE en premier — ils bloquent la facturation électronique —, puis la gestion documentaire rattachée aux dossiers, et enfin le registre de traitements, qui est le document le plus demandé et le plus absent. Voir les prestations d'Atalios Consulting ou demander un rappel.

Pour aller plus loin

• La base de connaissance : wiki et validation
• UBL, Factur-X et l'envoi des factures

En résumé

Quatre besoins transverses n'ont pas de réponse dans Odoo Community : classer des documents avec des droits, faire signer sans service tiers, tenir le registre RGPD, et disposer des référentiels normalisés qu'exige la facturation électronique. Parlons de vos documents.