La mise à jour de mars 2026 contient une ligne courte dans les notes de version officielles: "L'application Services sur Site a été supprimée. Ses fonctionnalités sont désormais intégrées à l'application Planification."
Courte, mais pas anodine. Pour les entreprises qui gèrent des techniciens itinérants — maintenance, installation, SAV, BTP — c'est une restructuration qui touche leur outil quotidien. Odoo a organisé un webinar dédié sur le sujet, ce qui confirme que cette fusion mérite davantage qu'une note de bas de page.
Voici ce qu'on voit concrètement depuis cette mise à jour, et les questions à se poser avant d'y passer.
Pourquoi Odoo a fusionné les deux apps
Field Service (Services sur Site) et Planification coexistaient depuis plusieurs années avec des périmètres qui se recoupaient de plus en plus. Les deux géraient des créneaux, des ressources, des tâches à assigner sur le terrain. La logique de planification était dupliquée, avec des vues Gantt et Kanban dans chacune des apps, et des passerelles parfois peu intuitives entre elles.
Le résultat sur le terrain : des clients qui maintenaient des configurations dans deux endroits différents, des exports entre apps, et des intégrateurs qui passaient du temps à expliquer pourquoi il fallait paramétrer la même chose à deux endroits.
Odoo a fait le choix d'une app centrale pour tout ce qui touche à la planification des ressources — humaines ou matérielles — et d'y intégrer les spécificités du travail terrain. C'est cohérent avec la direction prise depuis V18 : rationaliser le nombre d'apps, augmenter la profondeur fonctionnelle de chacune.
Ce que Planification gagne dans cette fusion
L'app Planification de V19.2 n'est plus seulement un outil de dispatch de créneaux. Elle hérite des fonctionnalités terrain de Field Service, et V19.2 y ajoute deux évolutions notables.
L'assignation de plusieurs ressources à un même créneau est maintenant native. Sur un chantier ou une intervention complexe, il est courant d'envoyer deux techniciens ensemble. Avant, il fallait créer deux créneaux séparés pour le même job — une source d'erreur fréquente et un vrai irritant pour les planificateurs.
Le lien entre créneau et tâche est désormais disponible directement dans Planification. Un créneau peut être associé à une tâche de projet spécifique. C'est le pont entre la logique de dispatch (qui va où, quand) et la logique de suivi opérationnel (qu'est-ce qui est fait, à quel stade). Ce lien existait dans Field Service via la génération automatique de tâches depuis une commande client — il est maintenant directement accessible dans l'app de planification.
Les fonctionnalités mobiles restent présentes : gestion des interventions depuis l'application, feuilles de temps, signature client, consommation de pièces. Ces fonctionnalités étaient au cœur de Field Service depuis V19.0 et ne disparaissent pas avec la fusion.
Ce qui peut coincer à la migration
Fusionner deux apps, c'est aussi fusionner deux bases de données de configuration. Voici les points à ne pas négliger pour une migration en V19.2 en Saas ou dans la future V20 en SH/on Premise.
Les personnalisations sur Field Service. Si des champs custom ou des vues Studio ont été créés sur l'app Field Service, il faut vérifier leur portabilité vers Planification. Une migration Odoo standard gère les données, pas nécessairement les personnalisations faites hors du chemin standard. C'est à vérifier avant toute mise à jour de production.
Les modules OCA. Le dépôt field-service de l'OCA regroupe plusieurs dizaines de modules communautaires — gestion des équipements, suivi des déplacements, rapports d'intervention personnalisés. Ces modules ciblent l'app fieldservice. Ils ne seront probablement pas compatibles avec la nouvelle architecture sans adaptation. Il faut inventorier ce qui est installé et prévoir les arbitrages.
Les droits d'accès. Field Service et Planification avaient chacun leur propre matrice de droits. Les utilisateurs qui avaient accès à l'une n'avaient pas forcément accès à l'autre. Après fusion, il faut revoir les profils pour s'assurer que les techniciens voient ce qu'ils doivent voir — et pas plus.
Les automatisations et actions serveur. Si des règles d'automatisation déclenchaient des actions sur des records Field Service (changement de statut, envoi d'email au client, génération de document), ces règles pointent vers un modèle qui n'existe plus. Elles devront être adaptées pour cibler les nouveaux objets dans Planification.
Un point important si vous êtes sur Odoo.sh ou on-premise : les versions intermédiaires comme la 19.2 sont réservées au SaaS. Votre prochain saut de version sera directement vers Odoo 20, attendu en septembre 2026. Ces changements sur Field Service et Planification s'appliqueront donc à vous à ce moment-là — vous avez du temps pour préparer la migration, mais autant commencer l'inventaire maintenant.
Ce que ça simplifie vraiment
Maintenant que les choses sont plus claires, l'avantage est tangible pour les équipes qui utilisaient les deux applications ensemble.
Le dispatcher qui jonglait entre l'onglet Planification pour les créneaux et l'onglet Field Service pour les tâches terrain travaille désormais dans une seule interface. Les vues Gantt et Kanban des deux apps sont unifiées — avec le code couleur amélioré et la planification par employé introduits dans les notes V19.2.
La traçabilité est aussi plus propre. Quand un créneau est lié à une tâche, l'historique d'une intervention — qui était là, combien de temps, quelle matière consommée — est centralisé dans un seul enregistrement plutôt que réparti entre deux apps.
Pour les PME qui utilisaient Field Service de façon basique (sans personnalisation lourde), la transition devrait être fluide. Pour celles qui ont construit des workflows complexes autour de cette app, un audit préalable s'impose.
Ce qu'il faut faire avant de migrer
Trois vérifications à faire avant de passer en V19.2 si vous utilisez Field Service :
- Inventaire des modules tiers et OCA installés sur votre instance. Un simple export de la liste des apps installées suffit pour identifier ce qui cible fieldservice.
- Revue des automatisations actives. Dans Paramètres > Technique > Automatisations, filtrer sur les modèles liés à Field Service.
- Test sur une instance de staging. Odoo propose la mise à niveau sur une base de test avant production pour les clients SaaS. Sur Odoo.sh, c'est une branche de staging. Dans les deux cas, tester le parcours complet — création d'une intervention depuis une commande client jusqu'à la facturation — avant de toucher à la production.
La fusion est logique et va dans le bon sens. Mais comme toute restructuration d'app dans Odoo, elle demande un passage en revue de ce qui a été construit autour. Le faire avant la migration, pas après.
Pour évaluer l'impact sur votre instance spécifique, contactez-nous — on regarde avec vous ce qui mérite attention.