Un projet consomme trois choses : du temps, des matières, et de l'argent. Odoo sait enregistrer le temps ; le reste demande des modules — et la prévision de charge n'existe pas du tout en Community.
Dix-huit modules communautaires traitent ces trois consommations, et les liens avec la vente qui les déclenche.
Résumé
Quatre modules traitent le temps et la charge : une application de prévision générant des lignes par rôle, une vue chronologie sur les projets et les tâches avec son enrichissement par les feuilles de temps, et un chronomètre qui enregistre l'heure de début et de fin plutôt qu'une durée saisie.
Quatre traitent les matières et l'argent : l'enregistrement des produits consommés sur une tâche, leur consommation avec de vrais mouvements de stock, l'usage d'ensembles de produits pour cette consommation, et le rattachement d'un budget analytique au projet. S'y ajoute le lien vers les achats et factures fournisseurs rattachés analytiquement.
Cinq relient la vente au projet : la copie de tâches plutôt que la création d'un projet à chaque commande, le choix manuel du projet et de la tâche avant confirmation, la récurrence des tâches configurée sur le produit, les provisions affichées dans le tableau de bord, et un modèle de description repris à la génération.
Quatre enfin traitent les textes : des modèles de description de tâche, une description dédiée au portail distincte de l'interne, des notes internes invisibles du client, et une automatisation d'opportunités après-vente depuis le projet.
L'essentiel
- Une application de prévision de charge par rôle — absente de la Community.
- Une vue chronologie sur projets et tâches, enrichie du temps passé.
- Un chronomètre qui enregistre début et fin, au lieu d'une durée déclarée.
- La consommation de stock depuis une tâche, avec de vrais mouvements.
- Un budget analytique rattaché au projet.
- Les achats et factures fournisseurs du projet, accessibles depuis sa fiche.
- La copie de tâches au lieu d'un nouveau projet à chaque commande.
- Deux descriptions : celle que lit le client, celle que lit l'équipe.
Ce que ces modules ajoutent à l'instance
| Famille | Modules | Nombre |
|---|---|---|
| Temps et charge | project_forecast_line, project_timeline, project_timeline_hr_timesheet, project_timesheet_time_control | 4 |
| Matières et argent | project_task_material, project_task_stock, project_task_stock_product_set, project_budget, project_purchase_link | 5 |
| Lien avec la vente | sale_project_copy_tasks, sale_project_task_selection, sale_project_task_recurrency, sale_project_reimbursement_cost, sale_project_task_description_template | 5 |
| Textes et suivi | project_task_description_template, project_task_description_portal, project_task_note, project_crm_postsale_automation | 4 |
Les menus ajoutés : l'application Forecast avec sa configuration et ses rôles de prévision, Feuilles de temps ▸ Démarrer le travail, et Projet ▸ Configuration ▸ Task Description Templates.
Prévoir la charge, et mesurer le temps
La prévision de charge — qui sera occupé à quoi dans six semaines — n'existe pas dans Odoo Community. C'est pourtant la question que pose toute société de services avant d'accepter une mission.
project_forecast_line installe une application de prévision à part entière : elle génère des lignes de prévision à partir des projets, des ventes et des congés, réparties par rôle — un rôle défini sur le poste ou sur la fiche employé —, avec une vue consolidée en graphique empilé.
Deux modules donnent une lecture visuelle du planning :
project_timelineajoute une vue chronologie aux projets et aux tâches, qui les situe dans le temps plutôt que dans une liste.project_timeline_hr_timesheetl'enrichit des informations de feuilles de temps : le prévu et le réalisé sur la même ligne de temps.
Le chronomètre
project_timesheet_time_control ajoute un chronomètre aux feuilles de temps : on démarre le travail, on l'arrête, et l'enregistrement porte l'heure exacte de début et de fin — pas seulement une durée déclarée en fin de journée.
La différence est mesurable : une durée reconstituée le vendredi pour la semaine est systématiquement arrondie, et sous-estime les interruptions. Un chronomètre enregistre ce qui s'est passé — à condition que les équipes acceptent de le démarrer.
Les feuilles de temps et leur validation sont traitées dans projets, rôles et feuilles de temps.
Les matières et l'argent du projet
| Module | Ce qu'il permet |
|---|---|
project_task_material | Enregistrer les produits consommés sur une tâche, sans mouvement de stock |
project_task_stock | Consommer des produits depuis une tâche avec de vrais mouvements de stock |
project_task_stock_product_set | Consommer un ensemble de produits d'un coup |
project_budget | Rattacher un budget analytique au projet, créé et consulté depuis sa fiche |
project_purchase_link | Accéder depuis le projet aux commandes d'achat et factures fournisseurs rattachées analytiquement |
Les deux premiers se distinguent nettement : le premier note ce qui a été consommé, le second le sort du stock. Pour un installateur, un dépanneur ou un atelier, c'est le second qui compte — sinon l'inventaire dérive à chaque intervention.
Le lien vers les achats est celui qui manque le plus en gestion d'affaire : savoir ce qu'un chantier a coûté suppose de voir ses commandes fournisseurs, pas seulement les heures passées. L'analytique les relie ; encore faut-il pouvoir les lire depuis le projet.
Le budget analytique s'appuie sur le module de budgets OCA ; les états financiers correspondants sont traités dans états financiers et budgets.
De la vente au projet
sale_project_copy_tasksajoute une option de suivi de service sur le produit : copier des tâches dans un projet existant au lieu de créer un nouveau projet à chaque commande. Pour une entreprise qui a un projet par client, c'est le comportement attendu.sale_project_task_selectionpermet de choisir manuellement le projet et la tâche de rattachement d'une ligne de service avant la confirmation du devis.sale_project_task_recurrencyconfigure, depuis la fiche produit, la récurrence des tâches générées à la confirmation — pour les contrats de maintenance et les abonnements de service.sale_project_reimbursement_costaffiche dans le tableau de bord du projet une section Provisions : les montants facturés d'avance au client.sale_project_task_description_templatefait reprendre un modèle de description sur les tâches générées depuis une commande.
Les deux premiers corrigent le même défaut : Odoo crée un projet par commande, ce qui produit au bout d'un an des dizaines de projets pour un même client. Les entreprises contournent en renommant et en déplaçant à la main.
La facturation de ces prestations est traitée dans contrats récurrents et abonnements et facturer une vente.
Ce que le client lit, et ce que l'équipe lit
| Module | Ce qu'il ajoute |
|---|---|
project_task_description_template | Des modèles de description réutilisables, injectés en un clic |
project_task_description_portal | Une description dédiée au portail client, distincte de la description interne |
project_task_note | Des notes internes sur la tâche, jamais visibles du client |
project_crm_postsale_automation | La création automatique d'opportunités de suivi après-vente depuis les projets |
La séparation des deux descriptions est la condition d'un portail client utilisable : sans elle, soit l'équipe s'autocensure — et la tâche perd son contenu technique —, soit le client lit des échanges qui ne lui sont pas destinés.
Les modèles de description standardisent ce qui doit l'être : une fiche d'intervention, un protocole de recette, une liste de contrôle. L'équipe ne réécrit pas, et rien n'est oublié.
Le dernier module ferme la boucle commerciale : un projet terminé génère une opportunité de suivi programmée — l'entretien annuel, le renouvellement, l'extension. C'est le chiffre d'affaires que les sociétés de services laissent le plus souvent passer.
Onze compléments : portail, droits et flux de développement
Ces modules ne forment pas une famille ; chacun répond à une situation précise, et quatre d'entre eux touchent au portail client.
| Module | Ce qu'il résout |
|---|---|
project_portal_task_visibility | Un utilisateur portail ne voit plus toutes les tâches d'un projet partagé, mais seulement celles qui le concernent |
project_no_portal | Le blocage complet, par société, de l'accès portail aux projets et aux tâches — une garantie technique, pas un réglage de visibilité |
project_update_portal | Les mises à jour de projet accessibles aux clients qui les suivent, sans leur ouvrir le reste |
project_share | La vue de partage d'un projet améliorée, avec le kanban en lecture seule |
project_administrator_restricted_visibility | Un administrateur de projets à visibilité restreinte : il configure comme un administrateur, sans voir tous les projets |
project_task_default_user | Des utilisateurs assignés par défaut, définis au niveau du projet ou de l'étape |
project_pivot | Une vue tableau croisé sur les projets |
project_task_create_date | La date de création disponible en colonne dans la liste des tâches |
project_kanban_form_direct_access | L'ouverture directe de la fiche projet depuis son nom en kanban |
project_task_pull_request | Un champ lien de pull request sur la tâche, obligatoire pour entrer dans certaines étapes |
project_task_pull_request_state | L'état de la pull request — brouillon, ouverte, fusionnée, fermée |
Les deux premiers traitent le même risque sous deux angles : par défaut, un utilisateur portail invité sur un projet voit toutes ses tâches. Pour une entreprise qui gère plusieurs clients dans un même projet, ou des tâches internes au milieu des tâches client, c'est une fuite.
L'administrateur à visibilité restreinte répond à une organisation fréquente : un responsable de direction qui doit paramétrer les projets de son périmètre sans accéder à ceux des autres directions.
Les deux derniers s'adressent aux équipes de développement : rendre obligatoire le lien de pull request pour passer une tâche en revue, et suivre l'état de cette PR depuis la tâche. C'est l'un des rares endroits du catalogue OCA où un flux de développement logiciel est outillé.
Limites connues
- La prévision de charge est une application entière : elle suppose des rôles définis, des postes renseignés et des congés tenus.
- Le chronomètre suppose l'adhésion des équipes : démarré une fois sur deux, il produit des données pires qu'une saisie hebdomadaire.
project_task_materialne bouge pas le stock : c'estproject_task_stockqui le fait. Confondre les deux fausse l'inventaire.- Le budget projet dépend du module de budgets OCA, à installer et paramétrer.
- La vue chronologie dépend d'un composant d'interface du dépôt
web. project_forecast_lineest peu documenté côté version dans le relevé : à vérifier sur le dépôt.
Identité technique
Les dix-huit modules viennent du dépôt OCA project, branche 18.0, en licences AGPL-3 et LGPL-3 selon le module. Plusieurs dépendent des feuilles de temps, de sale_project ou de stock ; la prévision de charge s'appuie en plus sur les congés, et la chronologie sur un composant du dépôt web.
Le dépôt project est désormais entièrement couvert : 67 modules en trois fiches — étapes et hiérarchie, identifier et organiser et celle-ci.
Questions fréquentes
Odoo Community permet-il de prévoir la charge des équipes ?
Pas nativement. project_forecast_line installe une application de prévision qui génère des lignes de charge à partir des projets, des ventes et des congés, réparties par rôle, avec une vue consolidée. C'est la question que pose toute société de services avant d'accepter une mission.
Quelle différence entre enregistrer et consommer du matériel sur une tâche ?
project_task_material note les produits consommés, sans toucher au stock. project_task_stock les sort réellement du stock, avec de vrais mouvements rattachés à la tâche. Pour un installateur ou un dépanneur, c'est le second qui compte : sinon l'inventaire dérive à chaque intervention.
Peut-on éviter qu'Odoo crée un projet par commande ?
Oui : sale_project_copy_tasks ajoute une option de suivi de service qui copie des tâches dans un projet existant au lieu d'en créer un nouveau. Et sale_project_task_selection permet de choisir le projet et la tâche avant confirmation. Sans eux, un client génère des dizaines de projets en un an.
Le client voit-il la description interne d'une tâche ?
Par défaut, oui. project_task_description_portal ajoute une description dédiée au portail, distincte de la description interne, et project_task_note des notes internes jamais visibles du client. Sans cette séparation, soit l'équipe s'autocensure, soit le client lit ce qui ne lui est pas destiné.
Comment savoir ce qu'un chantier a réellement coûté ?
En réunissant les trois consommations : le temps (feuilles de temps), les matières (project_task_stock) et les achats. project_purchase_link donne accès, depuis la fiche projet, aux commandes d'achat et factures fournisseurs rattachées analytiquement — la partie que les heures seules ne montrent pas.
Se faire accompagner
La rentabilité d'une affaire se calcule avec trois chiffres : les heures, les matières et les achats. La plupart des entreprises n'en ont qu'un dans leur ERP, et reconstituent les deux autres à la main — quand elles les reconstituent.
Nous branchons donc les trois avant de parler de prévision : un passé mesuré vaut mieux qu'un futur estimé sur des données incomplètes. La prévision de charge vient ensuite, et elle est alors crédible. 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
- Identifier et organiser les projets
- Projets, rôles et feuilles de temps
En résumé
Les trois consommations d'un projet enfin réunies : le temps mesuré au chronomètre, les matières sorties du stock pour de vrai, et les achats visibles depuis la fiche. Plus la prévision de charge par rôle, absente de la Community, et la séparation entre ce que lit le client et ce que lit l'équipe. Parlons de la rentabilité de vos affaires.
