Migration Odoo : les erreurs les plus fréquentes chez les PME suisses (et comment les éviter)

Passer à Odoo, c'est rarement un problème de logiciel. Dans la grande majorité des projets que nous accompagnons en Suisse romande, ce qui fait la différence entre un go-live serein et une migration Odoo qui dérape, ce sont quelques réflexes pris (ou pas) dès le départ.

Chez Nalios, chaque projet se termine par un « lessons learned » : ce qui a bien marché, ce qui a coincé, et ce qu'on change pour la suite. En relisant ces retours, les mêmes erreurs reviennent. Voici les cinq plus fréquentes, avec des exemples concrets (anonymisés) et la manière de les éviter.

01Vouloir tout implémenter d'un coup

Le réflexe : « Tant qu'on y est, on met tout en place : ventes, achats, stock, compta, RH, site web… et on bascule le même jour. »

Pourquoi ça coince : l'approche « big bang » multiplie les risques. Si un seul flux bloque le jour J, c'est toute l'entreprise qui en pâtit, et la confiance des équipes dans le nouvel outil en prend un coup dès le départ. Des utilisateurs démotivés dans les premières semaines, c'est souvent des mois de rattrapage.

Ce qu'on fait à la place : on découpe en phases. Chaque phase suit le même cycle : configuration, démo au référent interne, validation, formation, mise en production, puis retour d'expérience avant de passer à la suivante (nous détaillons ce cycle dans les étapes d’un projet Odoo réussi). Le premier objectif est de mettre rapidement un premier périmètre en production pour prouver la valeur, puis d'élargir.

Seule exception raisonnable : un périmètre CRM / Ventes / Facturation, très imbriqué, peut tout à fait démarrer d'un bloc.

À retenir : mieux vaut un premier flux qui tourne dans 2 mois qu'un ERP complet « presque prêt » dans 8.

02Vouloir tout automatiser avant de revoir les bases

Le réflexe : « On veut que les relances partent toutes seules, que les commandes se confirment automatiquement, que les rapports s'envoient chaque lundi… »

Pourquoi ça coince :

Automatiser un processus mal défini, c'est simplement produire des erreurs plus vite.

Tant que le plan comptable, les catégories de produits, les fiches clients ou les règles de stock ne sont pas propres, chaque automatisation repose sur du sable.

Exemple vécu : une PME de services souhaitait envoyer automatiquement par courrier postal de nombreux rapports de suivi via l'option d'envoi postal intégrée. Sur le papier, idéal. En pratique, des limites techniques (nombre de pages par envoi notamment) l'ont rendue inadaptée à leur volume : du temps investi pour une solution à reconstruire ensuite. Valider d'abord le flux manuel aurait révélé la contrainte bien plus tôt.

Ce qu'on fait à la place :

1. D'abord des données de base propres et un flux standard qui fonctionne « à la main » ;
2. Ensuite, on identifie les tâches répétitives réellement quotidiennes ;
3. Et là seulement, on automatise. Une automatisation utilisée tous les jours (confirmation en masse, par exemple) se justifie largement. Une automatisation « au cas où », rarement.

03Vouloir garder ses anciens fonctionnements… dans Odoo

Le réflexe : « Dans notre ancien système / notre fichier Excel, on faisait comme ça. Il faut que ce soit pareil dans Odoo. »

Pourquoi ça coince : reproduire à l'identique un outil vieux de 10 ou 15 ans, c'est importer aussi ses contournements, ses bricolages et ses limites. On paie un nouvel ERP pour… retrouver l'ancien. Chaque adaptation pour « faire comme avant » ajoute de la complexité, du coût et de la dette technique.

Ce qu'on fait à la place : notre principe, c'est remplacer plutôt que répliquer. Pour chaque besoin, on pose deux questions : quoi (le besoin réel) et pourquoi (l'enjeu métier). Très souvent, le standard d'Odoo répond au « pourquoi » d'une autre manière, parfois plus simple que l'ancien process.

C'est aussi l'occasion de remettre à plat certaines habitudes : plusieurs de nos clients ont profité du projet pour revoir leurs propres processus, en s'appuyant sur les bonnes pratiques de leur secteur.

Astuce : limitez aussi l'import d'historique au strict nécessaire. Dix ans de données dans le nouvel outil, c'est surtout dix ans d'incohérences à nettoyer. Notre équipe vous aide à définir ce qui mérite d'être repris pour votre migration Odoo.

04Développer directement pour 2 % des cas

Le réflexe : « Il arrive parfois que… donc il faut que le système le gère. »

Pourquoi ça coince : parler de développement spécifique pour 2 % des cas dès la première semaine du projet, c'est très bien, on peut le noter. Mais on ne doit pas perdre de temps sur ce genre de besoin. Ce qui importe, c'est la base : vos données, vos flux de tous les jours, votre formation… Si on regarde et qu'on discute de tous les cas possibles dès le début, on perd un temps précieux.

Ce qu'on fait à la place : chez nous, le développement arrive dans un deuxième temps. On applique la règle des 80/20 : on couvre les 80 % de besoins qui apportent l'essentiel de la valeur, et on challenge les 20 % restants. Accepter de regarder un développement plus tard, parfois même après la mise en production, permet de gagner énormément de temps.

Ça ne veut pas dire « jamais de développement ». Quand un besoin est quotidien, que toutes les options standard ont été explorées et qu'il fait gagner un vrai temps, on y va. Mais en connaissance de cause et en gérant les priorités, ce qui pèse aussi directement sur le coût de votre projet Odoo.

Le bon test : classez chaque demande en « must have » ou « nice to have ». Les « nice to have » attendent une phase ultérieure.

05Ne pas consacrer assez de temps au projet

Le réflexe : « On a pris un intégrateur, c'est lui qui s'en occupe. »

Pourquoi ça coince : un projet Odoo réussi, c'est du 50/50. L'intégrateur configure, conseille et forme ; mais c'est l'entreprise qui connaît son métier, prend les décisions, prépare ses données et teste (voir aussi notre comparatif se lancer seul ou se faire accompagner). En pratique, une heure de réunion génère environ 2h30 à 3 heures de travail côté client (validations, tests, préparation des données, to-do). Ce temps-là est ce qui vous rend autonome.

Exemple vécu : sur un projet, la responsable finance désignée n'avait pas le temps d'avancer sur ses tâches (plan comptable, catégories de dépenses…). Résultat : toute la partie facturation, qui en dépendait, était bloquée, et le projet a pris du retard.

Sur ce même projet, une autre dérive est apparue : jusqu'à six personnes en réunion, chacune posant directement ses questions au consultant. Le budget d'heures a fondu bien plus vite que prévu.

Ce qu'on fait à la place : on désigne dès le kick-off un Single Point of Contact (SPOC) :

• Qui connaît le métier et peut trancher ;
• Qui dispose de temps dédié dans son agenda ;
• Par qui passent toutes les demandes (pas de canaux parallèles) ;
• Qui devient l'expert Odoo interne, selon l'approche « train the trainer ».

Des spécialistes (comptable, responsable production…) peuvent rejoindre ponctuellement les séances qui les concernent. Mais le pilotage reste chez une seule personne.

Ce qui marche : chez plusieurs de nos clients industriels, un SPOC qui ouvre lui-même ses tickets sur le portail projet, les priorise et arbitre le budget a été la clé d'une collaboration fluide et d'une feuille de route claire.