Implémentation Odoo : de l'audit initial au go-live

Implémenter Odoo ne consiste pas à installer des modules et à saisir quelques paramètres. C'est un projet qui touche la façon dont l'entreprise facture, encaisse, déclare la TVA et, souvent, paie ses salaires. En Suisse, ces trois sujets — comptabilité, TVA, paie — sont encadrés par des règles précises, et un paramétrage qui les ignore au moment du cadrage se paie au premier bouclement, pas avant. C'est la différence entre un intégrateur qui installe un logiciel et une fiduciaire qui pense l'implémentation à partir de ce que la comptabilité doit produire in fine.

Cette page décrit la méthode que nous suivons, phase par phase, de l'audit préalable au support qui suit la mise en production. Elle traite aussi, sans détour, ce qui fait échouer ou dérailler un projet ERP : ce sont des causes connues, récurrentes, et évitables si elles sont anticipées.

Quand une entreprise est prête pour Odoo — et quand elle ne l'est pas encore

Odoo a du sens dès qu'une entreprise gère plusieurs processus qui aujourd'hui ne communiquent pas entre eux : facturation dans un outil, stock sur un tableur, salaires chez un tiers, sans vue d'ensemble. Le signal le plus clair est la ressaisie manuelle — la même information tapée deux ou trois fois dans des outils différents — et l'absence de visibilité en temps réel sur la trésorerie ou les marges.

À l'inverse, certains signaux indiquent qu'il vaut mieux attendre ou d'abord régler un problème en amont :

• Les processus actuels ne sont pas stabilisés. Si l'entreprise change encore régulièrement sa façon de facturer ou de gérer ses achats, informatiser un processus instable revient à figer le désordre.
• Aucune personne ne peut être libérée pour piloter le projet côté métier. Sans référent interne disponible, les décisions de paramétrage se prennent par défaut, souvent mal, et se corrigent plus tard à plus grand coût.
• Les données sources sont en très mauvais état (doublons massifs, plan comptable incohérent, aucun historique fiable) et personne n'est prêt à les nettoyer avant le projet.
• L'entreprise traverse une réorganisation majeure (fusion, changement de forme juridique, restructuration) qui va de toute façon changer les processus dans les mois qui viennent.

Dans ces cas, la meilleure décision est parfois de reporter le projet de quelques mois plutôt que de l'engager sur un terrain instable. Un audit préalable permet de trancher objectivement.

L'audit préalable

Avant tout paramétrage, nous documentons la situation existante :

• Processus en place : comment les devis, commandes, factures, paiements et salaires circulent aujourd'hui, et qui intervient à chaque étape.
• Outils actuels : logiciel de comptabilité, de facturation, de paie, tableurs, et la manière dont ils s'articulent — ou pas — entre eux.
• Données : où elles résident, sous quel format, leur degré de propreté (doublons, champs incomplets, incohérences de plan comptable).
• Volumes : nombre de clients, de fournisseurs, de références produits, d'écritures annuelles, d'employés — ces chiffres déterminent la complexité de la reprise de données et des tests.
• Contraintes réglementaires propres à l'activité : assujettissement TVA (taux applicables, méthode de décompte), obligations sectorielles, conventions collectives influençant la paie.

Cet audit produit une vision claire de ce qui existe et de ce qui doit changer — c'est la base du cadrage qui suit, pas une formalité.

Le cadrage : périmètre, modules, ce qu'on repousse

Le cadrage traduit l'audit en un périmètre de projet concret. C'est l'étape où se joue une grande partie du succès ou de l'échec ultérieur du projet, car elle fixe ce qui doit fonctionner au démarrage et ce qui peut attendre.

Définir le périmètre de la première phase

La règle la plus utile est simple à énoncer et difficile à respecter : démarrer avec le périmètre le plus restreint qui couvre les besoins réels de fonctionnement de l'entreprise, pas le périmètre le plus complet possible. Un projet qui tente de couvrir comptabilité, TVA, paie, CRM, inventaire et développements spécifiques dès le jour un multiplie les points de décision, les tests et les personnes à mobiliser en parallèle — et retarde justement le moment où le socle financier est fiable.

Choisir les modules

Le choix des modules découle directement du périmètre retenu. Pour la plupart des PME, le socle initial couvre la comptabilité, la facturation et les achats de base. Selon l'activité, on y ajoute dès le départ le CRM et la gestion commerciale, la gestion des stocks et des achats, ou la paie et les ressources humaines — mais uniquement si ces briques sont indispensables au fonctionnement quotidien, pas parce qu'elles existent dans le catalogue Odoo.

Ce qu'on repousse volontairement

Documenter explicitement ce qui est repoussé, et pourquoi, évite deux écueils : l'impression que quelque chose a été oublié, et la tentation de l'ajouter en urgence en cours de projet. Sont typiquement repoussés à une phase ultérieure : les intégrations avec des outils tiers non critiques, les rapports personnalisés avancés, les modules e-commerce ou de gestion de projet quand ils ne conditionnent pas le fonctionnement de base, et toute personnalisation qui n'a pas encore fait la preuve de sa nécessité une fois l'outil standard en usage.

La configuration

Une fois le périmètre validé, la configuration met en place les fondations techniques et organisationnelles du système :

• Société : raison sociale, forme juridique, coordonnées, devise de base, exercice comptable.
• Plan comptable : structure des comptes, regroupements, comptes de bilan et de résultat adaptés à l'activité réelle — pas seulement le plan par défaut.
• Positions fiscales et TVA : rattachement des comptes et des produits aux bons taux, gestion des opérations exonérées ou à l'étranger, méthode de décompte (effective ou taux de la dette fiscale nette selon l'éligibilité).
• Journaux : ventes, achats, banque, opérations diverses, avec les séquences de numérotation et les comptes de contrepartie corrects.
• Comptes bancaires : rattachement des comptes réels, formats d'import des relevés, paramétrage de la QR-facture pour l'émission et la réception de paiements.
• Droits d'accès : qui peut voir, saisir, modifier ou valider chaque type de document, par profil d'utilisateur.
• Flux de validation : circuits d'approbation des factures fournisseurs, des notes de frais, des commandes d'achat, selon les seuils et les responsabilités internes.

Ce travail de configuration est la partie la moins visible du projet et la plus déterminante pour la fiabilité des chiffres produits ensuite.

La localisation suisse : contrôler et compléter, pas seulement installer

Odoo installe automatiquement le module de localisation suisse (l10n_ch) dès que la société est configurée avec la Suisse comme pays. Ce module pose une base utile : structure de plan comptable adaptée aux usages suisses, taux de TVA courants (8.1 %, 2.6 % et 3.8 %, en vigueur depuis le 1er janvier 2024), et prise en charge de la QR-facture, standard suisse de paiement.

Le travail d'implémentation ne s'arrête pas là — il commence à ce moment précis. Cette base générique doit être :

• Contrôlée compte par compte, pour vérifier qu'elle correspond à la structure réelle de l'activité et non à un modèle générique.
• Adaptée aux positions fiscales effectives : taux applicables selon les prestations, méthode de décompte TVA, y compris la vérification de l'éligibilité aux seuils de la taxe au taux de la dette fiscale nette (chiffre d'affaires maximal de CHF 5'024'000 et impôt dû maximal de CHF 108'000 par an, en vigueur depuis le 1er janvier 2025 selon l'AFC).
• Complétée selon les journaux, les comptes bancaires et les flux réels de l'entreprise — la localisation de base ne connaît ni vos comptes bancaires, ni votre organisation interne.

C'est précisément à cette étape que la différence entre un intégrateur généraliste et une fiduciaire se voit : une localisation techniquement installée mais non contrôlée sur le fond produit des chiffres qui semblent corrects jusqu'au premier bouclement de TVA, où les écarts apparaissent. Pour tout ce qui concerne la tenue comptable courante une fois le système en place, voir notre page comptabilité Odoo.

La reprise des données

La reprise de données répond à trois questions distinctes, qu'il faut trancher séparément.

Ce qui se migre

En général : les fiches clients et fournisseurs actifs, le catalogue produits, les factures ouvertes (non encore encaissées ou payées), les soldes d'ouverture à la date de bascule, et les données nécessaires à la continuité opérationnelle immédiate (stock présent, contrats en cours).

Ce qui ne se migre pas systématiquement

L'historique comptable détaillé des exercices clos n'a en général pas besoin d'être rejoué écriture par écriture dans Odoo. Il reste accessible dans l'ancien système ou archivé au format PDF, ce qui satisfait les obligations légales de conservation sans alourdir la migration. De même, les fiches clients ou fournisseurs inactifs depuis longtemps, ou les données dont la fiabilité est douteuse, sont souvent volontairement laissées de côté plutôt que migrées « au cas où ».

La date de bascule

Elle se choisit en fonction du calendrier comptable de l'entreprise — le plus souvent en début d'exercice ou de période TVA, pour éviter de scinder une période en deux systèmes différents. Les soldes d'ouverture à cette date sont établis avec rigueur : ce sont eux qui garantissent la continuité comptable entre l'ancien système et Odoo. Pour un projet où le système source est déjà identifié et documenté, voir notre page dédiée à la migration de données.

Développements et intégrations, si nécessaires

Odoo standard couvre la majorité des besoins d'une PME. Un développement spécifique ou une intégration avec un outil tiers (site e-commerce, caisse enregistreuse, logiciel métier sectoriel) ne se justifie que lorsque le standard ne répond réellement pas au besoin — pas par principe. Chaque développement ajoute une dépendance qui devra être maintenue lors des montées de version futures ; nous documentons systématiquement ce qui est développé sur mesure et pourquoi, afin que ce choix reste traçable dans le temps.

Par prudence méthodologique, tout développement non strictement indispensable au fonctionnement de la première phase est repoussé : une personnalisation prématurée, décidée avant que les équipes n'aient utilisé le système standard, se fonde souvent sur une habitude de l'ancien outil plutôt que sur un besoin réel dans Odoo.

Les tests et la recette

La recette valide que le système paramétré produit des résultats corrects avant que l'entreprise n'y bascule ses opérations réelles.

• Jeux d'essai : données représentatives, construites à partir de cas réels de l'entreprise, pas de données génériques.
• Scénarios métier : parcours complets — de la commande à l'encaissement, de la réception d'une facture fournisseur à son paiement, du calcul d'un salaire à son décompte — testés de bout en bout, pas fonction par fonction isolément.
• Validation comptable : contrôle des balances, des rapprochements bancaires et d'une simulation de décompte TVA avant la bascule définitive. C'est le contrôle qui a le plus de valeur, car c'est celui qui révèle une configuration fiscale ou comptable mal calée avant qu'elle ne produise un chiffre officiel.

La recette est menée avec les utilisateurs qui utiliseront réellement le système au quotidien, pas uniquement avec le référent de projet — ce sont eux qui repèrent les écarts entre le paramétrage théorique et l'usage réel.

La formation des utilisateurs, par profil

Une formation générique, identique pour tous, laisse chacun se débrouiller avec les fonctions qui ne le concernent pas et néglige celles dont il a réellement besoin. La formation est donc construite par profil :

• Comptabilité et finance : saisie, lettrage, rapprochement bancaire, clôture périodique, décompte TVA.
• Ventes et facturation : devis, commandes, facturation, suivi des encaissements.
• Achats et stock, si ce périmètre est retenu : commandes fournisseurs, réceptions, inventaire.
• Ressources humaines, si la paie est dans le périmètre : gestion des dossiers employés, cycle de paie, décomptes sociaux.
• Direction : lecture des tableaux de bord et des indicateurs, sans nécessairement la saisie opérationnelle.

Négliger la formation est une cause d'échec aussi fréquente qu'un mauvais paramétrage technique : un système bien configuré mais mal compris génère des erreurs de saisie qui, elles, produisent de mauvais chiffres. Le détail de notre approche de formation est présenté sur la page formation Odoo.

Le go-live et la période de stabilisation

Le go-live est le moment où l'entreprise bascule définitivement ses opérations sur Odoo. Il est précédé d'un gel des saisies dans l'ancien système le temps de finaliser la reprise des données, puis suivi d'une période de stabilisation pendant laquelle les premiers cycles réels — première facturation, premier rapprochement bancaire, premier bouclement TVA — font remonter des écarts qu'aucune recette, même soignée, ne détecte entièrement à l'avance. Cette période est planifiée comme une phase du projet, avec un accompagnement renforcé, et non traitée comme une succession d'incidents imprévus.

Le support et l'amélioration continue

Une fois la stabilisation passée, l'entreprise bascule vers un support courant : questions d'utilisation, corrections de paramétrage mineures, accompagnement des clôtures périodiques, évolutions modestes au fil des besoins constatés. C'est aussi le moment où les modules et fonctionnalités volontairement repoussés lors du cadrage initial peuvent être réévalués et ajoutés, sur un socle désormais stable. Voir notre offre de support Odoo pour le détail de cet accompagnement continu.

Ce qui fait varier la durée et le budget d'un projet

Nous ne donnons pas de fourchette de durée ou de coût générique : elle dépendrait d'hypothèses que nous ne connaissons pas encore au moment d'écrire cette page. En revanche, les facteurs qui font varier un projet d'implémentation Odoo, à la hausse comme à la baisse, sont identifiables :

• Le périmètre retenu : nombre de modules activés dès la première phase, nombre de sociétés ou d'entités légales à configurer.
• L'état des données sources : des données propres et structurées se reprennent vite ; des données dispersées, incohérentes ou dupliquées demandent un travail de nettoyage préalable qui peut peser plus lourd que la configuration elle-même.
• La disponibilité du référent interne : un projet où les décisions se prennent rapidement avance régulièrement ; un projet où chaque validation attend plusieurs semaines s'étire d'autant.
• Le volume de développements spécifiques : chaque personnalisation ajoute un cycle de spécification, de développement et de test qui s'ajoute au paramétrage standard.
• La complexité réglementaire de l'activité : plusieurs taux de TVA, activité internationale, conventions collectives spécifiques à la paie, multi-sociétés — chacun de ces éléments ajoute des cas à paramétrer et à tester.
• L'édition retenue, Community ou Enterprise : ce choix influence à la fois les fonctionnalités disponibles d'emblée et le modèle de coût récurrent par utilisateur.
• La version d'Odoo installée : Odoo 19 est la version stable courante ; une version récente bénéficie d'un support éditeur plus long, ce qui limite les montées de version forcées à court terme.

C'est précisément pour peser ces facteurs sur votre situation réelle, et non sur un cas générique, que le projet commence par un audit et un cadrage documentés — pas par un devis établi avant d'avoir vu vos processus. Si votre entreprise est basée à Genève ou dans la région, voir aussi notre accompagnement Odoo à Genève.