Réponse courte : Un périmètre ciblé — CRM, ventes et facturation pour une PME aux données propres — se déploie en quatre à huit semaines. Un périmètre élargi avec reprise de données et multi-dépôts demande deux à quatre mois. Un projet industriel avec production et coûts de revient s’étale sur quatre à huit mois. Dans presque tous les cas, ce ne sont pas les tâches techniques qui déterminent le délai, mais la disponibilité des décideurs et l’état des données.
Les trois durées de référence
Ces fourchettes supposent un périmètre cadré à l’avance et un référent identifié côté client, disponible chaque semaine.
Ces durées correspondent au temps calendaire entre le lancement et la mise en production, pas au nombre de jours travaillés. Un projet de trois mois ne mobilise pas trois mois d’équipe à plein temps : il alterne des phases de travail intense et des périodes d’attente, de validation et de test côté client.
Cette distinction est importante pour comprendre pourquoi deux projets au même budget peuvent avoir des durées très différentes. Ce qui étire le calendrier n’est presque jamais la charge technique.
| Type de projet | Durée | Ce qui la détermine |
|---|---|---|
| Périmètre ciblé — CRM, ventes, facturation, PME de 5 à 10 utilisateurs | 4 à 8 semaines | Nombre de documents à personnaliser, volume de formation |
| Périmètre élargi — achats, stock multi-dépôts, comptabilité, 10 à 20 utilisateurs | 2 à 4 mois | Qualité des données à reprendre, complexité des règles de tarification |
| Périmètre industriel — MRP, qualité, coûts de revient, 20 utilisateurs et plus | 4 à 8 mois | Profondeur des nomenclatures, exigences de traçabilité, interfaces |
Les cinq phases et leur poids réel
La reprise de données est le poste dont l’amplitude est la plus large, et c’est celui qui fait exploser les plannings. Une base propre et bien structurée se reprend en quelques jours. Une base contenant des doublons, des références incohérentes et des soldes approximatifs devient un chantier à part entière, parfois plus long que la configuration elle-même.
La bonne nouvelle est que ce travail peut commencer avant le projet. Nettoyer votre fichier clients et votre catalogue produits pendant que vous choisissez encore votre intégrateur est le meilleur investissement de temps que vous puissiez faire.
| Phase | Part du délai | Ce qui s’y passe |
|---|---|---|
| Cadrage | 15 à 20 % | Ateliers métier, périmètre écrit, priorités, décisions structurantes |
| Configuration | 25 à 30 % | Paramétrage des applications, droits, documents, règles de gestion |
| Reprise de données | 20 à 35 % | Inventaire, nettoyage, codification, imports et contrôles |
| Tests et recette | 15 à 20 % | Scénarios réels joués par les utilisateurs, corrections, validation |
| Formation et démarrage | 10 à 15 % | Parcours par rôle, accompagnement renforcé les premières semaines |
Ce qui allonge réellement un projet
Après plusieurs projets, les causes de dérive se répètent avec une régularité frappante. Elles sont presque toutes organisationnelles.
L’absence de décideur disponible
C’est de loin la première cause. Un projet ERP génère des dizaines de décisions : quelle numérotation pour les documents, qui valide une remise au-delà d’un seuil, que faire des références obsolètes du catalogue. Si personne ne tranche, tout s’arrête.
Un référent qui consacre une demi-journée par semaine au projet vaut mieux qu’un comité de direction qui se réunit une fois par mois. La disponibilité compte davantage que le niveau hiérarchique.
Le périmètre qui s’étend en cours de route
Chaque demande ajoutée après le cadrage décale le planning, y compris les plus petites. L’effet est cumulatif et rarement perçu sur le moment : dix demandes « rapides » ajoutent facilement un mois.
La parade n’est pas de tout refuser mais de constituer une liste de phase deux. Les demandes y sont consignées, arbitrées après la mise en production, et traitées avec le recul de l’usage réel. Une partie disparaît d’elle-même.
Le développement avant le test du standard
Beaucoup de demandes de développement s’évanouissent après une démonstration du fonctionnement natif d’Odoo. L’utilisateur décrit son processus actuel et demande à le reproduire à l’identique, alors que l’outil propose une manière différente et souvent plus simple d’atteindre le même résultat.
Systématiquement tester le standard avant d’écrire une ligne de code économise du temps et du budget, et allège les montées de version futures.
La formation reléguée en fin de projet
Former la veille du démarrage garantit un rejet. Les utilisateurs découvrent l’outil sous pression, sans avoir pu poser de questions ni vérifier leurs propres données.
La formation efficace commence pendant la configuration : les référents manipulent, testent leurs cas réels, remontent les écarts. Le jour du démarrage devient alors une formalité.
Les périodes creuses non anticipées
Un projet qui traverse une clôture comptable, un pic saisonnier ou les congés d’été perd mécaniquement plusieurs semaines. Dans certains secteurs, la saisonnalité est telle qu’il faut choisir sa fenêtre avec soin.
Cela se planifie au cadrage, pas au moment où le retard est constaté.
Ce qui accélère un projet
Le déploiement par lots mérite une mention particulière. Livrer d’abord un flux critique, le faire fonctionner en production, puis ajouter le reste réduit le risque et donne des résultats visibles plus tôt. C’est aussi un excellent moyen de maintenir l’adhésion des équipes, qui constatent un bénéfice concret au lieu d’attendre six mois un grand basculement.
- Un périmètre volontairement restreint pour la première phase, quitte à élargir ensuite.
- Des données nettoyées avant le début du projet, notamment clients et catalogue.
- Un référent disponible chaque semaine, avec un mandat clair pour décider.
- Des décisions prises rapidement, même imparfaites : un choix révisable vaut mieux qu’un arbitrage repoussé.
- L’acceptation du standard Odoo là où il n’y a pas d’enjeu métier réel.
- Une recette organisée avec des scénarios écrits à l’avance, plutôt qu’une exploration libre.
Un calendrier type sur trois mois
Exemple d’un déploiement achats, stock, ventes et facturation pour une PME de quinze utilisateurs.
Vous remarquerez que la colonne de droite est aussi chargée que celle du milieu. C’est le point que cet article cherche surtout à faire passer : la durée d’un projet Odoo dépend au moins autant de vous que de votre intégrateur.
Un prestataire qui vous annonce un délai sans vous préciser ce qu’il attend de votre part à chaque étape vous vend un calendrier qu’il ne tiendra pas. Pour préparer correctement cette répartition, notre guide sur le cahier des charges Odoo détaille les informations à réunir en amont.
| Période | Travaux | Ce que vous devez fournir |
|---|---|---|
| Semaines 1-2 | Ateliers métier, cadrage, périmètre écrit et validé | Disponibilité des responsables, accès aux données actuelles |
| Semaines 3-5 | Configuration des applications, documents, droits d’accès | Validation des maquettes de documents, arbitrages de gestion |
| Semaines 4-8 | Inventaire, nettoyage et import des données, contrôles | Nettoyage des fiches clients et produits, validation des soldes |
| Semaines 8-10 | Recette sur scénarios réels, corrections | Utilisateurs référents mobilisés pour tester |
| Semaines 10-11 | Formation par rôle, préparation du démarrage | Disponibilité des équipes pour les sessions |
| Semaine 12 | Mise en production et accompagnement renforcé | Présence des référents, remontée rapide des blocages |
Questions fréquentes
Peut-on déployer Odoo en deux semaines ?
Pour un périmètre très restreint, avec des données propres et un seul utilisateur décideur, c’est envisageable. Mais un déploiement en deux semaines suppose d’accepter le standard sans adaptation et de renoncer à toute reprise d’historique. Pour la plupart des PME, quatre à huit semaines est un minimum réaliste.
Faut-il tout déployer en une fois ?
Non, et c’est rarement une bonne idée. Un déploiement par lots livre de la valeur plus tôt, réduit le risque et permet d’intégrer les retours des utilisateurs avant d’étendre le périmètre.
Quel est le meilleur moment de l’année pour démarrer ?
Une mise en production en début d’exercice simplifie beaucoup le travail comptable. Cela implique de lancer le cadrage trois à quatre mois plus tôt. Évitez également les pics saisonniers propres à votre activité.
Combien de temps mes équipes doivent-elles y consacrer ?
Comptez une demi-journée par semaine pour le référent principal, et deux à quatre jours au total pour chaque utilisateur référent, répartis entre ateliers, recette et formation. C’est un investissement, pas une variable d’ajustement.
Que se passe-t-il si le projet prend du retard ?
Le premier réflexe utile est d’identifier la cause réelle : décision en attente, données non préparées, périmètre étendu. Dans la plupart des cas, réduire le périmètre de la première phase permet de tenir la date de démarrage et de reporter le reste.
Le support continue-t-il après la mise en production ?
Oui. Les premières semaines d’exploitation révèlent toujours des ajustements. Notre support et maintenance Odoo couvre cette période et les évolutions ultérieures.
À retenir
Une bonne décision Odoo repose sur un périmètre priorisé, des données préparées, des scénarios testables et des utilisateurs impliqués. Demandez un rendez-vous pour appliquer cette méthode à votre contexte.