« La tâche 1 847 » ne veut rien dire au téléphone. « DEV-42 », si. Et une équipe projet n'est pas un champ « responsable » : c'est un ensemble de personnes avec des rôles, dont certaines relisent sans exécuter.
Vingt modules communautaires donnent aux projets une identité, une structure d'équipe et des droits.
Résumé
Cinq modules traitent l'identification : une clé de projet combinée à un numéro séquentiel pour les tâches, une séquence de projet, un code de tâche autonome et sa reprise dans le portail client, et l'affichage de l'identifiant technique dans le nom.
Six traitent la classification : des types de projet hiérarchiques applicables aux projets et aux tâches, des étiquettes hiérarchiques, restreintes à une société ou à une liste de projets, les étiquettes de tâche limitées à celles du projet, et les versions d'un projet.
Trois traitent la structure : des projets modèles dupliqués pour créer de nouveaux projets, la fusion de tâches en doublon, et les parties prenantes avec leur rôle.
Six enfin traitent les équipes et les droits : un système de rôles et d'affectations, des relecteurs sur une tâche, le rattachement aux départements et aux catégories d'employés, et la visibilité d'un projet restreinte à des groupes de sécurité, avec sa colle pour les feuilles de temps.
L'essentiel
- Une clé de projet et des tâches identifiées « DEV-42 », y compris dans le portail client.
- Des projets modèles dupliqués pour lancer un nouveau projet avec sa structure.
- Des types de projet hiérarchiques, applicables aux projets et aux tâches.
- Des étiquettes hiérarchiques, restreintes par société ou par projet.
- Les étiquettes de tâche limitées à celles du projet — fini les listes de cent valeurs.
- Un système de rôles et d'affectations pour composer les équipes.
- Des relecteurs sur une tâche, distincts des assignés.
- La visibilité d'un projet restreinte à des groupes de sécurité.
Ce que ces modules ajoutent à l'instance
| Famille | Modules | Nombre |
|---|---|---|
| Identification | project_key, project_sequence, project_task_code, project_task_code_portal, project_task_name_with_id | 5 |
| Classification | project_type, project_tag_hierarchy, project_tag_multicompany, project_tag_security, project_task_tag, project_version | 6 |
| Structure | project_template, project_merge, project_stakeholder | 3 |
| Équipes et droits | project_role, project_reviewer, project_department, project_hr, project_group, project_group_hr_timesheet | 6 |
Les menus ajoutés : Projet ▸ Affectations, Projet ▸ Configuration ▸ Rôles du projet, Types de projet, Project Version et Stakeholder Roles.
Donner un nom aux tâches
Odoo identifie une tâche par son numéro technique interne : 1 847, 1 848, 1 849 — une numérotation globale, sans rapport avec le projet. Au téléphone avec un client ou en réunion d'équipe, ce numéro n'aide personne.
project_keyattribue une clé courte au projet — « DEV », « PA » — et compose l'identifiant de chaque tâche avec un numéro séquentiel propre au projet : « DEV-42 ».project_task_codefournit une alternative : un code séquentiel unique par tâche, généré à la création, sans clé de projet.project_task_code_portalfait utiliser ce code dans le portail client, à la place de l'identifiant technique.project_sequenceapplique la même logique aux projets eux-mêmes, avec un nom d'affichage combinant code et libellé.project_task_name_with_idse contente d'afficher l'identifiant technique dans le nom et de permettre la recherche par ce numéro.
Les deux premiers se concurrencent : la clé de projet convient aux organisations qui raisonnent par projet, le code global à celles qui gèrent un flux continu de demandes. On choisit, on ne cumule pas.
La reprise dans le portail est le détail qui compte en relation client : le client voit le même identifiant que vous, et le cite dans ses messages.
Classer : types, étiquettes, versions
| Module | Ce qu'il apporte |
|---|---|
project_type | Des types de projet hiérarchiques, applicables aux projets et aux tâches |
project_tag_hierarchy | Une hiérarchie sur les étiquettes de projet, nativement plates |
project_tag_multicompany | Des étiquettes restreintes à une société |
project_tag_security | Des étiquettes limitées à une liste de projets autorisés |
project_task_tag | Les étiquettes proposées sur une tâche limitées à celles du projet |
project_version | Des versions propres à chaque projet, à affecter aux tâches |
Le cinquième résout un agacement universel : sur une instance partagée, la liste des étiquettes de tâche contient tout ce que toutes les équipes ont créé depuis deux ans. Restreindre aux étiquettes du projet rend la liste utilisable — et les étiquettes à nouveau fiables.
Les versions servent au développement logiciel et à tout ce qui se livre par lots : affecter une tâche à « v2.1 » permet de voir ce qui part dans la prochaine livraison.
Démarrer un projet, et nettoyer
project_templatepermet de désigner des projets comme modèles et d'en générer de nouveaux en dupliquant leur structure : étapes, tâches types, organisation.project_mergeajoute un assistant de fusion de tâches en doublon.project_stakeholderajoute les parties prenantes : des contacts associés au projet avec un rôle défini.
Le premier est celui qui change le lancement d'un projet : une entreprise qui fait dix fois le même type de mission — audit, installation, déploiement — recrée dix fois la même structure. Le modèle la fige une fois, et les projets démarrent en une minute.
Les parties prenantes répondent à un besoin distinct de l'équipe interne : le client, le maître d'œuvre, le bureau de contrôle, le fournisseur critique. Ils ne travaillent pas sur les tâches, mais le projet les concerne.
Les équipes, les relecteurs et les droits
Rôles et affectations
project_role introduit un système de rôles et d'affectations — un roster — pour organiser les équipes projet au-delà du champ « responsable ». Les rôles se configurent, et les affectations se gèrent depuis un menu dédié.
C'est la différence entre « qui est responsable » et « qui fait quoi » : sur un projet à dix intervenants, le second est la seule information utile — et elle vit d'ordinaire dans un tableur ou dans la mémoire du chef de projet.
project_reviewer ajoute des relecteurs sur une tâche, distincts des assignés. Dans tout processus où une production est vérifiée — code, document, plan, livrable —, cette distinction structure le travail.
Les droits
project_grouprestreint la visibilité d'un projet et de ses tâches à des groupes de sécurité, en complément du mécanisme standard. Son module de colle étend cette visibilité aux feuilles de temps.project_departmentrelie projets et tâches aux départements de l'entreprise.project_hrrelie les projets aux catégories d'employés.
La restriction par groupe est le complément du cloisonnement décrit dans sécuriser les accès Odoo : certains projets — fusion-acquisition, litige, projet confidentiel — ne doivent pas apparaître à toute l'entreprise.
Limites connues
- Clé de projet et code de tâche se concurrencent : choisir l'un des deux systèmes d'identification.
- Changer d'identification en cours de route laisse un historique hétérogène : à décider au démarrage.
- Les projets modèles figent une structure : utile pour les missions répétitives, contraignant pour les projets atypiques.
- La fusion de tâches est définitive : à réserver au nettoyage de doublons avérés.
- Les rôles supposent d'être tenus : un roster périmé est pire qu'un champ responsable.
- La restriction par groupe cache des projets : prévoir qui doit voir l'ensemble, direction comprise.
Identité technique
Les vingt modules viennent du dépôt OCA project, branche 18.0, en licences AGPL-3 et LGPL-3 selon le module. Trois dépendent du module RH (hr) et deux des feuilles de temps ; project_key et project_task_code_portal touchent au portail client.
Les familles voisines : étapes, statuts et hiérarchie et projets, rôles et feuilles de temps.
Questions fréquentes
Comment donner aux tâches un identifiant lisible ?
project_key attribue une clé courte au projet — « DEV » — et compose l'identifiant des tâches avec un numéro propre au projet : « DEV-42 ». project_task_code offre une alternative avec un code séquentiel global. Les deux se concurrencent : on choisit selon qu'on raisonne par projet ou en flux continu de demandes.
Le client voit-il le même identifiant de tâche que nous ?
Avec project_task_code_portal, oui : le code de tâche remplace l'identifiant technique dans le portail client. Le client cite alors la même référence que vous dans ses messages — ce qui supprime une source constante de malentendus.
Peut-on limiter les étiquettes proposées sur une tâche ?
Oui : project_task_tag restreint les étiquettes proposées à celles associées au projet. Sur une instance partagée, la liste native contient tout ce que toutes les équipes ont créé depuis des années — restreindre la rend utilisable et les étiquettes à nouveau fiables.
Peut-on créer un projet à partir d'un modèle ?
Oui, avec project_template : certains projets sont désignés comme modèles, et de nouveaux projets sont générés en dupliquant leur structure — étapes, tâches types, organisation. Pour une entreprise qui refait dix fois le même type de mission, le lancement passe d'une demi-journée à une minute.
Peut-on cacher un projet à une partie de l'entreprise ?
project_group restreint la visibilité d'un projet et de ses tâches à des groupes de sécurité, et un module de colle étend cette restriction aux feuilles de temps. C'est nécessaire pour les projets confidentiels — fusion-acquisition, litige — mais il faut prévoir qui conserve une vue d'ensemble.
Se faire accompagner
L'identification des tâches est une de ces décisions qu'on prend par défaut et qu'on regrette : au bout de deux ans, changer de système laisse un historique à deux vitesses. Mieux vaut trancher au démarrage — clé de projet ou code global — et s'y tenir.
Nous traitons ensuite les rôles et les relecteurs, qui structurent le travail réel, et les droits en dernier. Un projet confidentiel mal cloisonné se remarque ; un projet mal identifié se subit tous les jours. Voir les prestations d'Atalios Consulting, notre méthode ou demander un rappel.
Pour aller plus loin
- Étapes, statuts et hiérarchie des tâches
- Projets, rôles et feuilles de temps
- Sécuriser les accès Odoo
En résumé
Des tâches qui s'appellent « DEV-42 » jusque dans le portail client, des projets lancés depuis un modèle plutôt que recréés, des étiquettes limitées à leur projet, et des équipes décrites par des rôles au lieu d'un champ responsable. Plus la visibilité restreinte quand un projet doit rester confidentiel. Parlons de vos projets.
