Ce que tu vas apprendre
Structurer un projet
Modes, options, dépendances, jalons, niveau d'accès — les 7 décisions à prendre dès la création.
Configurer le kanban
5 stages, ordre, couleurs, repli (fold) — et le piège v19 sur le champ kanban_state retiré.
Industrialiser
Templates, sous-projets vs sous-tâches, 5 erreurs structurelles à éviter pour préparer l'analytique et la facturation.
1. Cas pratique — une ESN qui pilote trois missions consulting en parallèle
Prenons le cas d'une ESN qui vient de signer trois missions consulting au cours du même trimestre. Toutes démarrent en mai 2026, toutes ont une équipe dédiée, toutes devront être facturées au temps en fin de mission. Trois clients, trois équipes, un seul outil pour piloter : Odoo Project en édition Community.
Mission 1 — Audit Réseau chez un client industriel. Pilotée par le chef de mission technique. Diagnostic infrastructure réseau, livrable cartographie + plan d'action. Forfait avec dépassement régie.
Mission 2 — App Métier chez un second client. Pilotée par le chef de mission développement. Application interne de suivi de production. Régie pure, sprints de 2 semaines.
Mission 3 — Déploiement WiFi chez un troisième client. Pilotée par la cheffe de mission infrastructure. Installation 18 bornes sur 3 sites, livraison clé en main avec portail client. Forfait.
Au-dessus de ces trois pilotes, la responsable opérationnelle suit l'avancement global depuis le kanban consolidé et relance les chefs de mission quand une tâche bloque trop longtemps.
📖 Définition — Vocabulaire ESN
Projet = unité de gestion Odoo (un client, une mission, un compte analytique). Programme = ensemble de projets liés stratégiquement. Mission = appellation commerciale du projet vis-à-vis du client.
Question pédagogique : comment le chef de la mission Audit Réseau structure-t-il son projet pour que la facturation au temps et l'analyse de rentabilité soient possibles à terme ?
2. Créer un projet : modes & options
Le menu de création vit dans Projet → Projets → Nouveau. La fiche projet expose en v19 une dizaine de champs essentiels, mais six décisions seulement structurent vraiment la suite.
Nom du projet (name) — règle de nommage : préfixer par le client ou par le code mission. « Audit Réseau — Client Industriel A » lit mieux qu'« Audit Réseau » tout court dans une liste de 40 projets.
Client (partner_id) — souvent issu d'une opportunité CRM gagnée. Le client provient souvent d'une opportunité CRM — voir l'article CRM dans Odoo 19.
Gestionnaire (user_id) — le chef de mission désigné pour piloter la livraison côté ESN. Un chef de mission par projet : c'est lui qui assume le calendrier, l'avancement et l'escalade.
Dates de début et fin (date_start, date) — bornent la mission. Servent au filtre calendrier et à l'analyse de retard.
Jalons (allow_milestones=True) — active la fonctionnalité jalons sur le projet. Indispensable dès qu'une facturation par étape est prévue.
Dépendances entre tâches (allow_task_dependencies=True) — active le champ depend_on_ids sur les tâches. À cocher dès la création si tu sais que des tâches devront en attendre d'autres.
Renommer le mot « Tâches » (label_tasks) — un champ texte libre. Mettre « Lots » pour un projet construction, « Tickets » pour un projet support, « Phases » pour un projet de migration. Le libellé custom apparaît partout dans l'interface du projet.
3. Stages kanban : configurer, ordonner, replier
Le kanban est le cœur visuel du projet. Pour configurer ses colonnes, ouvre le projet, passe en vue Tâches, mode Kanban, puis clique sur « + Ajouter une colonne ». Quatre champs gouvernent un stage (project.task.type) :
name— libellé visible en tête de colonne. Court, sans verbe (« En cours », pas « Tâches en cours d'exécution »).sequence— ordre d'affichage. Convention : 10, 20, 30, 40… (laisse de la place pour intercaler).color— index couleur 0 à 10 mappé sur la palette Odoo. Utile pour distinguer visuellement les colonnes "saines" des colonnes "à risque".fold— siTrue, la colonne est repliée par défaut. Réservée aux états temporaires (Bloqué) ou de fin de vie (Clôturé) qui ne polluent pas la vue principale.
Sur la mission Audit Réseau, cinq stages structurent la livraison : À cadrer (sequence=10, color=4 bleu) · En cours (20, color=2 orange) · Bloqué (30, color=1 rouge, fold=True) · Livraison (40, color=10 vert) · Clôturé (50, color=8 gris, fold=True). Cinq stages, cinq couleurs distinctes, deux colonnes repliées : la vue reste lisible quand 30 tâches s'accumulent.
⚠️ Piège v19 — kanban_state retiré
Le champ legacy kanban_state n'est plus disponible sur project.task en Odoo 19. Il a été remplacé par un champ state avec les valeurs 01_in_progress, 02_changes_requested, 03_approved, 1_done, 1_canceled, 04_waiting_normal. Si une vue héritée ancienne référence kanban_state, elle échouera silencieusement à l'upgrade. Audit obligatoire des vues custom XML avant migration vers v19.
Pour assigner un manager différent par stage, encore faut-il avoir configuré le module RH — voir Les employés dans Odoo 19.
4. Équipes & accès : privacy_visibility
Le champ privacy_visibility détermine qui peut voir et toucher le projet. Trois niveaux sont disponibles en v19 :
followers
Projet privé
Seuls les suiveurs explicitement ajoutés voient le projet et ses tâches. Réservé aux dossiers sensibles (audit interne, M&A, négociation).
employees
Visible à tous les employés
Niveau par défaut recommandé pour les missions internes. La mission Audit Réseau passe en employees : tout collaborateur de l'ESN consulte l'avancement, seul le gestionnaire et les assignés modifient.
portal
Partagé avec le client
Le client final du déploiement WiFi accède à ses tâches depuis /my/projects, en lecture seule par défaut. Idéal quand la transparence vis-à-vis du commanditaire fait partie du contrat.
Le champ collaborator_ids complète ce dispositif : il liste les utilisateurs externes (sous-traitants techniques, freelances, partenaires) qui doivent voir et agir sur le projet sans avoir le statut d'employé. Sur la mission WiFi, deux installateurs sous-traitants apparaissent dans collaborator_ids — ils saisissent leurs comptes-rendus de pose, rien d'autre.
5. Sous-projets vs sous-tâches : matrice de décision
À la première complexification, la question tombe : faut-il découper en sous-tâches ou créer un sous-projet ? Les deux mécanismes existent en v19, mais ils ne servent pas le même usage.
Sous-tâche — champ parent_id sur project.task. La sous-tâche reste dans le même projet, hérite du compte analytique parent, partage les stages parents. Sert à découper le travail d'une livraison atomique. Sur la mission Audit Réseau, la tâche « Cartographie réseau » éclate en sous-tâches « Inventaire équipements », « Trace switches », « Trace routeurs », « Schéma final » — quatre lots d'une même livraison, même équipe, même budget.
Sous-projet — créer un projet enfant qui pointe le parent via parent_id sur project.project. Chaque projet a son propre compte analytique, ses propres stages, sa propre équipe. Sert aux phases longues ou facturables séparément. Si la mission WiFi inclut une phase « Audit préalable » facturée en régie séparément de la « Pose des bornes » facturée au forfait, deux projets distincts s'imposent.
💡 Astuce — Règle de décision 3 critères
| Critère | Sous-tâche | Sous-projet |
|---|---|---|
| Durée | < 5 jours | > 2 semaines |
| Équipe | Identique | Différente |
| Budget facturable | Partagé | Séparé |
Deux critères sur trois en faveur du sous-projet → créer un projet enfant. Sinon, rester en sous-tâche.
Pour relier un devis à un projet, voir Les ventes dans Odoo 19.
6. Templates de projet is_template
Au troisième projet identique, la question du template tombe d'elle-même. Champ booléen is_template = True sur la fiche projet : le projet sort des listes opérationnelles et devient utilisable comme modèle. L'action contextuelle « Utiliser comme modèle » apparaît dans la statusbar : un clic crée un nouveau projet pré-configuré avec les mêmes stages, tags, niveau de privacy, et options activées (jalons, dépendances).
Côté ESN, un projet template « Mission Consulting Type » contient 5 stages standardisés (À cadrer · En cours · Bloqué · Livraison · Clôturé), trois tags par défaut (consulting, forfait, mission), privacy_visibility = employees, jalons activés. Chaque nouvelle mission démarre depuis ce template en 30 secondes au lieu de 15 minutes de configuration manuelle.
Bonnes pratiques template : ne pas mettre de tâches dans le template (sauf option explicite « Inclure les tâches » à la duplication), garder un libellé clair commençant par « [TEMPLATE] », documenter en description les conventions de nommage des projets dérivés.
7. Vues CE disponibles : 5 vues + alerte Gantt EE
Une fois le projet structuré, cinq vues natives Community pilotent la lecture quotidienne :
Kanban
Pipeline visuel par stage. Vue par défaut, idéale pour la mêlée quotidienne.
Liste
Édition rapide en lot, tri multi-colonnes, filtres avancés.
Calendrier
Deadlines et échéances sur grille jour/semaine/mois. Remplace en CE une partie de la lecture temporelle.
Pivot
Durée moyenne par étape, charge par assigné, volume tâches par mois. Cœur du reporting.
Graph
Bar/line/pie sur les mêmes axes pivot. Présentation directe pour les comités.
🔵 CE vs EE — vue Gantt
La vue Gantt (dépendances temporelles, planning de charge multi-projets) est nativement disponible uniquement en Odoo Enterprise. En Community, le pilotage temporel se reconstitue via la vue Calendrier filtrée par stage + le pivot durée. L'article F11·2 de cette saison détaille les contournements concrets et trois patterns éprouvés pour piloter sans Gantt.
Pour l'analyse pivot, le réflexe est similaire à celui de la facturation — voir Facturation et paiements.
8. Bonus : 5 erreurs structurelles fréquentes
❌ Confondre stage projet et stage tâche
Deux modèles distincts en v19 : project.project.stage pilote le stage du projet entier dans la vue kanban des projets (vision portfolio), project.task.type pilote le stage de chaque tâche à l'intérieur d'un projet. Erreur classique : créer 8 stages sur le modèle projet alors que la cible visée était 8 colonnes kanban dans un projet.
❌ Le projet "fourre-tout" client
Un seul projet « Client X » qui agrège toutes les missions du même client → impossible de mesurer la rentabilité par mission, le compte analytique mélange tout, la facturation au temps est imprécise. Règle structurante : un projet = une mission facturable.
❌ Oublier de lier le compte analytique
Sans account_id renseigné sur le projet, aucune mesure de rentabilité possible — les coûts (timesheet, achats) ne se rattachent à rien. L'article F11·4 reviendra en détail sur le sujet ; en attendant, créer systématiquement un compte analytique au moment de la création du projet.
❌ Privacy followers par défaut sans réflexion
Le projet devient invisible des collègues qui pourraient aider en cas d'urgence (le chef de mission est en vacances et personne ne voit le dossier). Préférer employees sauf raison documentée.
❌ Reproduire un projet sans template
Au troisième projet identique recopié manuellement, deux heures sont perdues par projet. Au cinquième, la configuration diverge silencieusement entre projets — chacun a des stages légèrement différents, des tags incohérents, des privacy non alignées.
Pour l'analytique, lire La comptabilité dans Odoo 19 — base sur laquelle s'appuie la rentabilité projet.
Conclusion
Tu sors avec une fondation propre : nommage projet, stages kanban ordonnés, privacy maîtrisée, choix sous-projet vs sous-tâche tranché, templates en place. La fondation est posée. Le prochain article F11·2 ouvrira la mécanique des tâches — priorités, deadlines, dépendances — et listera honnêtement ce que la Community ne couvre pas que l'Enterprise débloque.
Voir aussi dans ce hub Projet & Services
F11·1 — Démarrer ses projets dans Odoo CE
Structure, kanban, équipes — la fondation.
Articles complémentaires
#44 — Les achats dans Odoo 19
Cycle métier complet, même approche structurelle qu'un projet bien découpé.
#58 — Les employés dans Odoo 19
Prérequis RH pour les feuilles de temps — voir F11·3.