Combien de temps dure une implémentation Odoo dans une PME ?

Le temps d'une implémentation Odoo dans une PME se compte d'abord en heures de travail, puis en semaines de calendrier : l'estimateur de projet d'Odoo recommande de 25 à 200 heures de consultant selon le nombre d'employés et les applications retenues, et indique que 80 % des projets de ce type sont mis en production en ce nombre d'heures ou moins. La durée réelle en mois dépend ensuite de quatre facteurs que vous maîtrisez en grande partie : le périmètre de démarrage, la reprise des données, la part de développement spécifique et la disponibilité de votre référent.

Une durée annoncée au détour d'un salon ou d'un forum ne veut rien dire tant qu'on ne sait pas ce qu'elle couvre. Cet article vous donne les repères publiés par des sources reconnues, les facteurs qui étirent un calendrier, et les décisions que vous pouvez prendre dès maintenant pour qu'il reste court.

Combien de temps faut-il compter, en heures et en mois ?

Commençons par le seul repère chiffré que publie l'éditeur. Sur la page de ses Success Packs, des forfaits d'heures de consultant dédié, Odoo propose un estimateur de projet : on indique le nombre d'employés et les familles d'applications, et il recommande un pack de 25, 50, 100 ou 200 heures. Pour une entreprise de 20 employés qui coche Ventes & CRM, Logistique et Fabrication, il affiche :

« 80% des projets de ce type sont mis en production en 100 heures ou moins. » Odoo, page Success Packs, estimateur de projet pour 20 employés avec Ventes & CRM, Logistique et Fabrication (consultée en octobre 2026).

Avec les mêmes applications et 40 employés, la recommandation passe à 200 heures. Deux précisions changent la lecture de ces chiffres. D'abord, ce sont des heures de travail, pas des semaines : 100 heures, c'est un peu plus de 14 journées de 7 heures, et 200 heures un peu moins de 29. Ce nombre ne dit rien du calendrier : tout dépend du nombre de jours par semaine que le projet occupe, chez l'intégrateur comme chez vous.

Ensuite, ce sont des heures de consultant. Le temps de vos équipes n'y figure pas : les ateliers, les essais, le nettoyage des fichiers, la formation des collègues. Le calendrier dépend donc aussi d'une disponibilité que l'estimateur ne mesure pas.

Prenons un exemple simple. Si le responsable logistique d'une PME de 20 personnes ne peut libérer qu'une demi-journée par semaine, le volet stock avancera au rythme de cette demi-journée, quel que soit le nombre d'heures prévues côté intégrateur. Le même volet, avec deux jours par semaine, peut avancer jusqu'à quatre fois plus vite en calendrier pour le même nombre d'heures.

La bonne question n'est donc pas « combien de mois ? », mais « combien d'heures, et à quel rythme ? ». C'est elle qu'il faut poser à tout intégrateur qui vous annonce une date, et c'est elle que vous devez vous poser avant de bloquer l'agenda de vos équipes.

Pourquoi une étude ERP annonce-t-elle près de 17 mois ?

Du côté des études sur les projets ERP, l'ordre de grandeur change. Panorama Consulting, un cabinet de conseil américain, publie des études sur les projets ERP à partir des réponses d'entreprises utilisatrices. Son rapport 2017 repose sur 342 réponses recueillies entre mars 2016 et février 2017.

« Dans l'ensemble, la durée moyenne de mise en œuvre était de 16,9 mois. » Panorama Consulting Solutions, 2017 ERP Report (traduit de l'anglais).

Avant d'en tirer une conclusion pour votre PME, regardez qui répond. Le même rapport précise que la majorité des organisations interrogées déclarent au moins 50 millions de dollars de chiffre d'affaires annuel, avec une moyenne de 445 millions. Sur la dernière année étudiée, le coût moyen d'un projet y atteint 1,3 million de dollars.

Ce sont des entreprises et des projets d'une autre taille que ceux d'une PME de 10 à 50 salariés. Ce chiffre de 16,9 mois n'est donc pas un repère de durée pour vous. Le rapport reste pourtant utile pour une autre raison : il dit ce qui fait déraper les calendriers.

59 % des répondants déclarent avoir dépassé leur calendrier initial. Les deux premières causes de dépassement citées sont l'élargissement du périmètre (19 %) et les problèmes de données (16 %). Ce sont précisément les deux leviers que la suite de cet article traite en priorité, parce que ce sont des décisions avant d'être des sujets techniques.

Quels facteurs allongent vraiment le calendrier ?

Voici les quatre facteurs à examiner en premier. Aucun n'est d'abord technique : chacun renvoie à une décision prise, ou évitée, par l'entreprise.

Le périmètre de démarrage

Chaque application ajoutée au démarrage (ventes, achats, stock, fabrication, comptabilité) ajoute du paramétrage, des essais et de la formation. C'est mécanique. L'élargissement du périmètre en cours de route, lui, arrive en tête des causes de dépassement relevées par Panorama.

L'ordre compte autant que la taille. Notre guide d'implémentation décrit des cycles courts qui prennent les besoins du plus simple au plus complexe. L'exemple d'Ogust Food (compléments nutritionnels culinaires pour lutter contre la dénutrition en établissement de santé) le montre bien. En paramétrant d'abord la gestion commerciale, la brique la plus « banale », l'équipe a découvert que l'entreprise ne vend pas ses sauces à l'unité, mais en cartons et en boîtes.

Tout le catalogue a été restructuré autour de ce conditionnement réel avant de toucher au stock. Commencer par la logistique aurait fait calculer chaque mouvement et chaque inventaire sur une unité de vente fausse, et il aurait fallu tout défaire. Refaire, c'est du calendrier perdu.

La reprise des données

Deuxième cause de dépassement chez Panorama, la donnée consomme du temps à chaque étape : extraction, nettoyage, mise au format, import, contrôle. Notre guide cite le cas de Solution Industrie, négociant en pièces industrielles qui venait de Ciel. Quand les utilitaires d'export d'un logiciel ancien sont limités, une seule extraction propre peut coûter des demi-journées, parfois des journées entières de travail.

Chaque année d'historique ajoutée au périmètre se paie en jours de nettoyage qui retardent la mise en production. Le levier est donc simple : importer ce qui sert au démarrage (articles, clients et fournisseurs actifs, stocks, factures et commandes ouvertes) et laisser l'historique consultable dans l'ancien outil, en lecture seule.

Le périmètre à reprendre, le déroulé en sept étapes et les erreurs classiques, comme vouloir tout migrer ou nettoyer trop tard, sont expliqués dans notre page qui détaille comment migrer ses données vers Odoo.

Côté outil, Odoo fournit des modèles d'import pour les données les plus courantes, et un bouton Tester qui vérifie que les données sont valides avant de les importer. La documentation officielle rappelle que les imports sont définitifs et ne peuvent pas être annulés. Un fichier testé tôt, c'est une mauvaise surprise de moins la semaine de la bascule.

Toi quand tu attends depuis ce matin que ton vieux logiciel comptable sorte enfin un export exploitable.

Le développement spécifique

Un développement spécifique demande une spécification, du développement, des tests et une intégration. Il allonge donc le chemin jusqu'à la mise en production, et il pèse ensuite sur chaque montée de version.

Notre guide montre l'ordre inverse avec Voltra Lighting (lampes de table sans fil rechargeables pour l'hôtellerie et la restauration de luxe). L'entreprise avait de vrais besoins de pilotage pour ses grands comptes. Elle a d'abord travaillé plusieurs semaines sur des flux 100 % standard avec sa responsable des opérations, avant que soient construits ses tableaux de bord. Ceux-ci reposaient alors sur des besoins constatés dans l'outil. Développés dès le premier jour, ils auraient reposé sur des hypothèses, et il aurait fallu les refaire.

Les quatre niveaux d'adaptation, du standard au développement spécifique en passant par Studio et les modules tiers, ainsi que les questions à se poser avant d'écrire la moindre ligne de code, sont détaillés dans notre article sur le développement spécifique dans Odoo et les cas où il vaut mieux l'éviter.

La disponibilité du référent

Notre guide décrit un référent côté entreprise, le SPoC, qui doit être disponible, légitime et capable de trancher. Il comprend les choix faits dans Odoo, teste les flux et devient peu à peu le référent interne de l'outil.

Chaque décision qu'il ne peut pas prendre dans la semaine décale la suivante. Un intégrateur peut paramétrer vite ; il ne peut pas décider à votre place si un avoir se fait avant ou après le retour de la marchandise, ni qui valide un achat au-delà d'un certain montant. Ces arbitrages appartiennent à l'entreprise, et leur délai s'ajoute directement au calendrier.

Toi quand tu expliques à l'équipe que le référent Odoo, c'est toi, entre deux devis et le point production du lundi.

Comment se découpe le calendrier d'un projet par cycles ?

Un calendrier lisible se découpe en phases et en cycles, pas en un grand bloc de « mise en place ». Notre guide d'implémentation décrit cette logique : un atelier de lancement où l'on valide ensemble un processus métier de A à Z, puis des cycles courts, chacun consacré à une partie précise du périmètre : ventes, achats, stock, comptabilité ou support.

Les essais ne sont pas repoussés à la fin. Le guide décrit une base de test ouverte à vos équipes et un rendez-vous hebdomadaire de 2 heures. Vos utilisateurs y rejouent leurs scénarios réels, les blocages sont ajustés dans la semaine, et les mêmes scénarios sont rejoués la semaine suivante pour mesurer le chemin parcouru.

Une anomalie trouvée en semaine 3 coûte un ajustement dans la semaine ; la même anomalie trouvée le jour de la bascule coûte un arrêt d'activité. C'est toute la différence entre un calendrier tenu et un calendrier qui glisse sans que personne ne l'ait vu venir.

Ce découpage peut se suivre dans l'application Projet d'Odoo : une étape par phase, une tâche par cycle, et sur chaque tâche une date de début et une date de fin prévues. Le retard d'un cycle se voit alors dans la semaine où il apparaît, pas au moment de la mise en production.

Cette méthode, de la configuration aux tests métiers en passant par la reprise des données, le rôle du référent et la préparation des équipes, est décrite étape par étape, avec ses cas réels, dans notre guide pour réussir une implémentation Odoo.

Comment raccourcir la durée sans bâcler le projet ?

Raccourcir un projet ne veut pas dire sauter des étapes. Cela veut dire retirer ce qui n'a pas besoin d'être là le jour du démarrage. Cinq décisions y contribuent, et toutes se prennent du côté de l'entreprise.

• Trier les besoins avant le premier atelier : indispensable au démarrage, important, ou pour plus tard. Une phase 2 n'est pas un échec, c'est un calendrier tenu.
• Désigner un référent et lui libérer du temps, noir sur blanc, dans son planning, pour toute la durée du projet.
• Limiter la reprise aux données utiles au démarrage, et commencer le nettoyage des fichiers dès le cadrage plutôt que la semaine de la bascule.
• Utiliser d'abord le standard d'Odoo, et n'envisager un développement spécifique qu'après l'avoir éprouvé sur des cas réels.
• Tester chaque semaine sur vos vrais scénarios plutôt qu'une seule fois à la fin.

Le premier point se prépare avant même de choisir un intégrateur. Chaque service arrive avec sa liste, et tout ce qui n'est pas trié au départ risque de revenir sous forme de demande en cours de projet, c'est-à-dire sous la forme de ce que Panorama classe en tête des causes de dépassement.

Pour faire ce tri, notre outil de cahier des charges express vous fait classer vos besoins par application Odoo en Indispensable, Important ou Plus tard, en une dizaine de minutes, puis produit un PDF à partager avec votre équipe et votre expert-comptable.

Une dernière précision : ces décisions ne réduisent pas le travail nécessaire, elles retirent le travail inutile. Un démarrage sur trois applications bien testées laisse la place d'ajouter les suivantes ensuite, sur une base saine, plutôt que d'ouvrir sept chantiers en même temps.

Quand peut-on dire que l'implémentation est terminée ?

La durée d'une implémentation se mesure jusqu'à la mise en production, pas jusqu'à la dernière idée d'amélioration. Notre guide fixe ce qui doit exister à ce moment-là :

• une base Odoo configurée de manière complète ;
• des flux métiers testés, ajustés et validés ;
• des données reprises et nettoyées ;
• des référents internes formés et confiants ;
• une organisation prête pour la mise en production.

Tant qu'un de ces points manque, la date de bascule reste théorique. Quand ils sont tous là, la bascule devient une formalité, parce que les flux ont déjà été exécutés des dizaines de fois par les personnes qui les utiliseront.

Les améliorations qui arrivent ensuite relèvent de l'accompagnement après la mise en production, pas de l'implémentation. Les mélanger, c'est se donner un projet qui ne finit jamais. Les séparer, c'est accepter qu'un ERP vive et s'enrichisse, mais à partir d'une date de démarrage tenue.

En résumé : comptez en heures, découpez en cycles, tenez le périmètre et la donnée, et protégez le temps de votre référent. Ce sont ces décisions qui permettent à un projet de PME de tenir son calendrier.

Article rédigé par Billy Felicie

Expert en intégration Odoo chez Hors du Commun (Lyon). J'accompagne les PME dans la mise en place de leurs outils numériques et l'optimisation de leurs processus métiers depuis plus de 5 ans.