Une maintenance préventive qui tient dans un champ « tous les 90 jours » n'est pas un plan. Une machine a plusieurs échéances — graissage mensuel, contrôle semestriel, révision annuelle — et chacune consomme des pièces, du temps et de l'argent.
Quinze modules communautaires font de l'application Maintenance un outil de gestion, et terminent le dépôt.
Résumé
Trois modules traitent les plans : un modèle de plan de maintenance rattaché à l'équipement, avec un référentiel de genres de maintenance reporté sur la demande générée ; la création d'activités à partir du plan ; et un module masquant la récurrence native, pour éviter deux mécanismes concurrents.
Trois modules traitent la demande : une séquence de numérotation, des étiquettes, et la liste des employés concernés.
Trois modules traitent les pièces : la consommation depuis le stock — autorisation et entrepôt par défaut, liste de transferts, type et emplacement de consommation par entrepôt, avec deux analyses dédiées —, le lien avec les commandes d'achat, et la création d'équipements depuis un achat.
Six modules enfin traitent le temps, l'argent et les autres applications : les projets et leurs jalons rattachés aux équipements et aux demandes, les feuilles de temps avec heures planifiées, restantes et avancement, un contrôle de temps par minuteur, le rattachement de l'équipement à son écriture comptable d'acquisition, le lien avec les réparations, et le lien avec les tickets d'assistance.
L'essentiel
- Plusieurs plans par équipement, avec leur genre de maintenance.
- La récurrence native masquée, pour n'avoir qu'un mécanisme.
- Des pièces consommées depuis le stock, avec entrepôt par défaut.
- Un emplacement de consommation par entrepôt.
- Des feuilles de temps sur la demande : planifié, restant, avancement.
- Un minuteur de démarrage et d'arrêt d'intervention.
- L'équipement relié à son écriture comptable d'acquisition.
- Des ponts vers les achats, les réparations et les tickets.
Ce que ces modules ajoutent à l'instance
| Famille | Modules | Nombre |
|---|---|---|
| Plans | maintenance_plan, maintenance_plan_activity, maintenance_plan_only | 3 |
| Demande | maintenance_request_sequence, maintenance_request_tags, maintenance_request_employee | 3 |
| Pièces | maintenance_stock, maintenance_request_purchase, maintenance_purchase | 3 |
| Temps et projets | maintenance_project, maintenance_timesheet, maintenance_timesheet_time_control | 3 |
| Coûts et ponts | maintenance_account, maintenance_request_repair, maintenance_helpdesk_mgmt | 3 |
Les menus : Maintenance ▸ Maintenance ▸ Plans de Maintenance, Maintenance ▸ Configuration ▸ Genres de maintenance et Request Tags, Maintenance ▸ Analyse ▸ Product Moves et Stock Moves.
Les plans de maintenance préventive
Le standard d'Odoo attache une récurrence unique à l'équipement : une périodicité, une durée. Une machine réelle a trois à cinq échéances différentes, de périodicité et de nature distinctes — et les faire tenir dans un seul champ revient à n'en suivre qu'une.
maintenance_plan crée un plan de maintenance comme modèle à part entière, rattaché à l'équipement, avec le nombre de plans et une indication d'équipe requise. Un référentiel de genres de maintenance — graissage, contrôle réglementaire, révision — se reporte sur chaque demande générée, aux côtés du plan d'origine.
maintenance_plan_activity permet de définir dans le plan des activités qui seront créées en même temps que la demande. C'est ce qui transforme une demande en consigne : relever les heures, vérifier le niveau, consigner la mesure.
maintenance_plan_only est un module technique qui masque les réglages de récurrence natifs. Son utilité est d'éviter la coexistence de deux mécanismes de planification — celui d'Odoo et celui des plans — dans la même instance.
Deux mécanismes de récurrence actifs produisent des demandes en double, que les équipes clôturent en bloc faute de savoir laquelle est la bonne. Masquer le mécanisme natif n'est pas un détail d'affichage : c'est la condition d'un préventif crédible.
Trois modules complètent la demande : maintenance_request_sequence lui donne une numérotation, maintenance_request_tags des étiquettes avec leur référentiel, et maintenance_request_employee la liste des employés concernés. Le dernier a un README réduit à sa catégorie ; son champ est relevé sur instance.
Les pièces consommées
maintenance_stock est le module le plus riche du lot. Il ajoute :
| Modèle | Champs ajoutés |
|---|---|
| Équipement | Autoriser les consommations, entrepôt de consommation par défaut |
| Demande | Les deux mêmes, plus une liste de transferts |
| Entrepôt | Un type de consommation et un emplacement de consommation |
| Mouvement, ligne de mouvement, transfert | L'équipement et la demande de maintenance concernés |
Deux analyses apparaissent sous Maintenance ▸ Analyse : les mouvements de produits et les mouvements de stock liés à la maintenance.
C'est le chaînon qui permet de répondre à la question du coût : une intervention qui a consommé trois roulements et un litre d'huile a un coût matière connu, imputé à l'équipement.
maintenance_request_purchaserelie les commandes d'achat aux demandes de maintenance — le cas de la pièce commandée spécialement, ou de l'intervention sous-traitée.maintenance_purchasepermet de créer des équipements depuis un achat : la facture du matériel crée la fiche d'équipement, sans ressaisie.
Le temps et les projets
maintenance_project rattache les équipements et les demandes à des projets : un projet et une tâche par défaut pour le préventif sur l'équipement ; un projet, une tâche et un jalon sur la demande ; et sur le projet comme sur le jalon, les listes et compteurs d'équipements et de demandes.
maintenance_timesheet ajoute les feuilles de temps à la demande, avec les heures planifiées, les heures restantes, l'avancement et le total saisi. La ligne analytique porte la demande de maintenance.
maintenance_timesheet_time_control ajoute un contrôle de temps par minuteur : démarrer et arrêter l'intervention, au lieu de saisir une durée de mémoire en fin de journée.
Le temps passé en maintenance est la donnée la plus souvent absente et la plus décisive : sans elle, le coût d'une panne se résume aux pièces, et l'arbitrage entre réparer et remplacer se fait à l'intuition.
Les feuilles de temps et leur contrôle sont traités plus largement dans facturer le temps : arrondis et budgets.
Les coûts et les ponts
maintenance_account relie l'équipement à sa ligne d'écriture comptable et à son mouvement d'acquisition, et ajoute sur la ligne d'écriture une catégorie d'équipement, une liste d'équipements et leur nombre. Son README est réduit à sa catégorie ; les champs sont relevés sur instance.
C'est le raccord entre la valeur comptable d'un bien et son historique d'entretien — les deux informations nécessaires pour décider d'un remplacement.
maintenance_request_repairest un pont vers l'application Réparation : une demande de maintenance peut déclencher un ordre de réparation, avec sa nomenclature de pièces et sa main-d'œuvre.maintenance_helpdesk_mgmtrelie les tickets d'assistance aux demandes de maintenance : un client signale une panne par ticket, un technicien travaille sur une demande.
Le second est utile au mainteneur qui intervient chez ses clients : le ticket porte la relation client, la demande porte le travail. Voir la gestion des tickets d'assistance.
Limites connues
- Ne pas faire coexister les plans et la récurrence native : installer
maintenance_plan_onlyavec les plans, sous peine de demandes en double. - Trois modules ont un README réduit à leur catégorie :
maintenance_request_employee,maintenance_accountetmaintenance_purchase. Leurs champs sont relevés sur instance. maintenance_stockdemande un paramétrage d'entrepôt : type et emplacement de consommation, sans lesquels la consommation de pièces ne fonctionne pas.- Les feuilles de temps de maintenance dépendent du module de projets (
maintenance_project) : la chaîne de dépendances est longue. - Le minuteur dépend du contrôle de temps des projets (
project_timesheet_time_control), une brique du dépôt des feuilles de temps. maintenance_request_repairdépend du modulerepairetmaintenance_helpdesk_mgmtdu modulehelpdesk_mgmt: deux applications supplémentaires à installer et à paramétrer.- Aucun de ces modules ne fournit d'indicateur de disponibilité (taux de rendement synthétique, temps moyen entre pannes) : les données existent, les rapports restent à construire.
Identité technique
Les quinze modules viennent du dépôt OCA maintenance, branche 18.0 — dont les 31 modules sont désormais tous documentés ici —, tous en licence AGPL-3. Les dépendances externes : stock, purchase, project, hr_timesheet, account, repair, helpdesk_mgmt, hr_maintenance et project_timesheet_time_control.
L'autre fiche du dépôt : parc d'équipements : hiérarchie, emplacements, statuts et contrats.
Questions fréquentes
Odoo gère-t-il plusieurs échéances de maintenance par machine ?
Pas en standard : il attache une récurrence unique à l'équipement. maintenance_plan crée des plans de maintenance comme modèles à part entière, avec un référentiel de genres — graissage, contrôle réglementaire, révision — reporté sur chaque demande générée. Une machine réelle a trois à cinq échéances distinctes.
Faut-il désactiver la récurrence native quand on installe les plans ?
Oui, c'est exactement le rôle de maintenance_plan_only, qui masque les réglages natifs. Deux mécanismes actifs produisent des demandes en double, que les équipes clôturent en bloc faute de savoir laquelle est la bonne — et le préventif perd toute crédibilité.
Comment imputer les pièces consommées à une intervention ?
Avec maintenance_stock : autorisation de consommation et entrepôt par défaut sur l'équipement et la demande, type et emplacement de consommation par entrepôt, et l'équipement comme la demande portés sur les mouvements et transferts. Deux analyses apparaissent sous Maintenance ▸ Analyse.
Peut-on chronométrer une intervention de maintenance ?
Oui : maintenance_timesheet ajoute les feuilles de temps à la demande — heures planifiées, restantes, avancement — et maintenance_timesheet_time_control ajoute un minuteur de démarrage et d'arrêt. Sans temps passé, le coût d'une panne se résume aux pièces et l'arbitrage réparer/remplacer se fait à l'intuition.
L'application Maintenance fournit-elle un taux de disponibilité ?
Non. Aucun de ces modules ne calcule de taux de rendement synthétique ni de temps moyen entre pannes. Les données nécessaires existent — demandes, temps, pièces, équipements structurés — mais les rapports restent à construire.
Se faire accompagner
La maintenance préventive échoue presque toujours de la même façon : un planning posé au démarrage, des demandes générées, personne ne les clôture, et six mois plus tard l'application est abandonnée. La cause est rarement l'outil — c'est l'absence de ce qui rend la clôture utile : pièces imputées, temps saisi, coût visible.
Nous installons donc la chaîne complète avant le premier plan — stock, temps, coûts — et nous commençons par un seul genre de maintenance sur un seul atelier. Un préventif suivi vaut mieux qu'un préventif complet. Voir les prestations d'Atalios Consulting ou demander un rappel.
Pour aller plus loin
En résumé
Une maintenance préventive qui tient dans un champ « tous les 90 jours » n'est pas un plan. Quinze modules donnent à l'application sa chaîne complète : plusieurs plans par machine, pièces imputées depuis le stock, temps chronométré, coût d'acquisition relié. Parlons de votre maintenance.
