Toute entreprise qui envoie quelqu'un chez un client a le même problème : savoir qui va où, avec quoi, et ce qui a été fait. Odoo Community n'a rien pour cela nativement — la communauté a construit une application entière.
Et c'est bien d'une application qu'il s'agit : 1 301 champs et 28 menus pour le seul module central. Ce n'est pas un module qu'on installe pour voir : c'est un domaine fonctionnel qui se déploie.
Résumé
Ce n'est pas un module mais une application entière : 1 301 champs, 28 menus et 10 groupes de droits pour le seul module central, avec cinq modèles de base — Lieux, Travailleurs, Équipes, Équipements, Ordres de service — et un écran de dispatching.
Deux pièges avant toute promesse : fieldservice_account ne facture pas — le dépôt le décrit comme un module de traçabilité et de navigation —, et les extensions de la suite s'activent par cases à cocher dans les paramètres du module central, pas en les installant.
L'essentiel
- Cinq modèles de base : Lieux, Travailleurs, Équipes, Équipements, Ordres de service — et un écran de dispatching quotidien.
- Les modules complémentaires s'activent par cases à cocher dans l'écran Paramètres du module, pas par installation séparée visible.
fieldservice_recurring: récurrence fondée surdateutil.rrule— « le premier lundi du mois », « tous les jours ouvrés ».fieldservice_sale: une commande de vente confirmée génère automatiquement les ordres d'intervention.fieldservice_accountne génère aucune facture : c'est un module de traçabilité et de navigation, pas de facturation automatique.fieldservice_stock: le matériel à livrer sur le lieu d'intervention, et un entrepôt par territoire.
Ce que la famille ajoute à l'instance
| Module | Modèles créés | Champs | Menus | Version |
|---|---|---|---|---|
fieldservice | 5 | 1 301 | 28 | 18.0.5.8.1 |
fieldservice_recurring | 3 | 175 | 4 | 18.0.1.2.0 |
fieldservice_stock | 0 | 33 | 2 | 18.0.2.1.0 |
fieldservice_sale | 0 | 21 | 0 | 18.0.1.2.2 |
fieldservice_account | 0 | 17 | 0 | 18.0.1.1.0 |
L'écart entre la première ligne et les autres dit tout : fieldservice est l'application, les quatre autres sont des raccordements à des domaines existants d'Odoo — comptabilité, ventes, stock — plus un moteur de récurrence.
Le module central crée aussi 10 groupes de droits, ce qui est considérable et cohérent : un technicien, un dispatcheur, un responsable d'équipe et un administrateur n'ont pas à voir la même chose.
Les cinq modèles de base structurent tout le reste :
| Modèle | Ce qu'il représente |
|---|---|
| Lieux | L'endroit où l'intervention a lieu — distinct du client, qui peut en avoir plusieurs |
| Travailleurs | Les personnes qui interviennent, avec leurs compétences et leur territoire |
| Équipes | Les regroupements de travailleurs |
| Équipements | Le parc installé chez le client, qu'on vient entretenir ou réparer |
| Ordres de service | L'intervention elle-même, avec ses étapes |
La distinction client / lieu est la plus importante à comprendre avant de paramétrer : un syndic a vingt immeubles, une enseigne a trente magasins. L'intervention se rattache au lieu, la facture au client.
Où le trouver dans Odoo
Le module ajoute son propre menu racine, Service sur site, avec 28 entrées. Les principales :
| Menu | Ce qu'on y fait |
|---|---|
| Service sur site ▸ Opérations | Le dispatching quotidien et les ordres de service |
| Service sur site ▸ Données de base | Lieux, travailleurs, équipes, équipements |
| Service sur site ▸ Configuration ▸ Commandes | Types de commande, étiquettes, étapes |
| Service sur site ▸ Opérations ▸ Recurring Orders | Les ordres récurrents (module _recurring) |
| Service sur site ▸ Rapport ▸ Inventaire | Le matériel par lieu (module _stock) |
Le point de navigation à connaître : les extensions de la suite ne s'activent pas en les installant puis en cherchant un nouveau menu. Elles s'activent par des cases à cocher dans l'écran Paramètres du module fieldservice. Installer fieldservice_stock sans cocher l'option correspondante donne l'impression que rien ne s'est passé.
fieldservice_account : ce qu'il ne fait pas
C'est le module de la famille dont le nom induit le plus en erreur, et il vaut d'être lu avant de promettre quoi que ce soit à un client.
« Il ne génère aucune facture automatiquement : c'est un pur module de traçabilité et de navigation, la création du lien entre ligne de facture et ordre devant se faire via un autre module ou un développement. » — description relevée du module.
Ce qu'il fait réellement :
- Il relie les ordres de service aux factures et avoirs clients, via les lignes de facture.
- Il ajoute des boutons de navigation croisée : depuis un ordre, voir ses factures ; depuis une facture, voir les ordres.
- Il introduit une case « facturable » sur les étapes d'ordre.
Autrement dit : la facturation d'une intervention n'est pas automatique avec ce seul module. C'est fieldservice_sale qui fait le lien dans l'autre sens — une commande de vente qui génère des ordres — et c'est de ce côté qu'il faut regarder si l'objectif est « je vends une prestation, elle se planifie, elle se facture ».
C'est exactement le genre de limite qu'une documentation doit dire avant un projet, pas après. Voir la gestion d'une entreprise de services avec Odoo.
fieldservice_recurring : un moteur de récurrence de calendrier
C'est le module qui transforme le Field Service en outil de contrats d'entretien — et sa force vient d'une bibliothèque : dateutil.rrule.
Concrètement, cela signifie une expressivité de niveau calendrier, pas une simple périodicité :
- « tous les 3 mois »
- « le premier lundi du mois »
- « tous les jours ouvrés »
- « le dernier vendredi de chaque trimestre »
Le module ajoute trois objets de configuration et un écran d'exploitation :
| Objet | Rôle |
|---|---|
| Frequencies | Une fréquence élémentaire |
| Frequency Rule Set | Un ensemble de règles combinées |
| Recurring Templates | Le gabarit de l'ordre à générer |
| Recurring Orders | L'écran des récurrences actives |
Les ordres à venir sont générés par une tâche planifiée. C'est le point à vérifier après installation — comme pour tous les modules à cron, une tâche inactive produit un silence, pas une erreur.
175 champs pour ce seul module : la flexibilité de rrule se paie en nombre de paramètres. C'est utilisable, mais ce n'est pas un écran qu'on confie à un utilisateur sans l'avoir paramétré pour lui.
Les deux raccordements : ventes et stock
fieldservice_sale : vendre une prestation qui se planifie
C'est le module central pour toute organisation qui vend des prestations réalisées sur site. Le principe : un produit marqué comme tel génère, à la confirmation de la commande de vente, un ou plusieurs ordres d'intervention.
Il dépend de fieldservice, de fieldservice_account et de sale_management — l'enchaînement complet devis → commande → ordres → facturation suppose donc les trois.
Limite répertoriée : le dépôt souhaite pouvoir déduire la branche — et donc la liste de prix d'un nouveau partenaire — à partir d'une adresse. Ce n'est pas fait. En multi-entités avec des tarifs par zone, le tarif reste à poser à la main.
fieldservice_stock : le matériel sur le lieu d'intervention
Celui-ci répond à une question que tout technicien pose : quel matériel doit être sur place ?
- Savoir quel matériel doit être livré à une localisation d'intervention.
- Suivre les mouvements de stock associés à un ordre, directement depuis sa fiche.
- Gérer un entrepôt différent par territoire, en configuration multi-entrepôts.
La troisième capacité est celle qui compte dans une entreprise à plusieurs agences : le technicien de l'agence sud ne prend pas son matériel à l'entrepôt nord. Voir la gestion des stocks et de la traçabilité.
Limites connues
Les dépôts renvoient la feuille de route et les défauts ouverts de l'application Field Service à un fil GitHub dédié, plutôt que de les lister module par module. Quatre limites se dégagent de ce que nous avons relevé :
fieldservice_accountne facture pas. C'est un module de traçabilité. L'automatisation de la facturation vient defieldservice_sale, ou d'un développement.fieldservice_sale: pas de déduction de la branche ni de la liste de prix depuis une adresse.- Les extensions s'activent par cases à cocher dans les paramètres du module central — une installation sans activation ne produit rien de visible.
- La taille de l'application est une limite en soi : 1 301 champs, 28 menus, 10 groupes de droits. Ce n'est pas un module qu'on déploie en une après-midi.
La dernière mérite d'être prise au sérieux. Nous ne l'installons jamais « pour voir » : le Field Service se déploie sur un périmètre réduit — un type d'intervention, une équipe — avant d'être étendu.
Identité technique
| Module | Version | Licence | Dépend de |
|---|---|---|---|
fieldservice | 18.0.5.8.1 | AGPL-3 | base_geolocalize, base_territory, contacts, resource |
fieldservice_account | 18.0.1.1.0 | AGPL-3 | account, fieldservice |
fieldservice_recurring | 18.0.1.2.0 | AGPL-3 | fieldservice |
fieldservice_sale | 18.0.1.2.2 | AGPL-3 | fieldservice, fieldservice_account, sale_management |
fieldservice_stock | 18.0.2.1.0 | AGPL-3 | fieldservice, stock |
Les cinq viennent du dépôt OCA field-service, branche 18.0, qui compte 36 modules documentés. Ils font partie de notre pack services (81 modules), au-delà du socle commun.
Pour les métiers concernés, voir plombier, électricien, chauffagiste, paysagiste et entretien d'espaces verts et le BTP.
Questions fréquentes
Odoo Community gère-t-il les interventions terrain ?
Pas nativement : il n'y a rien pour cela dans l'édition de base. Le dépôt OCA field-service fournit une application complète — 1 301 champs, 28 menus, 10 groupes de droits pour le seul module central — avec lieux, travailleurs, équipes, équipements, ordres de service et un écran de dispatching.
fieldservice_account facture-t-il les interventions ?
Non, et c'est le malentendu le plus coûteux de cette famille : il relie les ordres aux factures et ajoute des boutons de navigation croisée, mais ne génère aucune facture. L'automatisation vient de fieldservice_sale — une commande de vente confirmée génère les ordres — ou d'un développement.
Pourquoi l'installation d'un module de la suite ne change-t-elle rien ?
Parce que les extensions s'activent par des cases à cocher dans l'écran Paramètres du module fieldservice, pas simplement en les installant. C'est une architecture propre, et c'est une source de confusion : installer fieldservice_stock sans cocher l'option correspondante ne produit rien de visible.
Jusqu'où va le moteur de récurrence ?
Loin : fieldservice_recurring s'appuie sur dateutil.rrule, ce qui permet d'exprimer « le premier lundi du mois », « tous les jours ouvrés » ou « le dernier vendredi de chaque trimestre ». La contrepartie est le nombre de paramètres — 175 champs — et une tâche planifiée à activer.
Peut-on gérer un entrepôt par agence ?
Oui, avec fieldservice_stock : il permet un entrepôt différent par territoire en configuration multi-entrepôts. C'est ce qui évite qu'un technicien de l'agence sud prépare son matériel depuis l'entrepôt nord, et c'est souvent la raison principale d'installer ce module.
Se faire accompagner
C'est le domaine le plus lourd de tout notre catalogue : 1 301 champs, 28 menus, 10 groupes de droits, et cinq modules qui s'activent par cases à cocher. Déployé d'un bloc, il échoue ; déployé sur un type d'intervention et une équipe, il fonctionne et s'étend.
Nous le cadrons en commençant par le modèle de données — la distinction client / lieu / équipement — puis un périmètre réduit, les droits par rôle, et la facturation en dernier. C'est le cœur de nos prestations d'intégration, et notre méthode est faite pour ce genre de projet. Demander un rappel.
Pour aller plus loin
- helpdesk_mgmt : tickets, portail client et temps passé
- Plombier, électricien, chauffagiste : les trois flux
- Le socle commun : les 57 modules de chaque instance
En résumé
Une application entière, pas un module : 1 301 champs, 28 menus, et une distinction client / lieu / équipement à comprendre avant tout paramétrage. Deux pièges — fieldservice_account ne facture pas, et les extensions s'activent par cases à cocher dans les paramètres du module central. Parlons de vos interventions.
