Implémentation Odoo ERP, ajustée à votre entreprise.

Une implémentation Odoo se déroule par phases. Cadrer les processus, paramétrer Odoo standard en face, n'écrire du code que là où l'entreprise diffère réellement, reprendre les données, faire tester sur de vrais enregistrements par les personnes qui utiliseront le système, puis démarrer un groupe de modules à la fois. Chaque phase se termine par quelque chose que vous pouvez ouvrir et valider.

Cadrage et périmètre

Nous parcourons les processus destinés à vivre dans Odoo — comment un devis devient une commande, un bon de livraison puis une facture, qui valide quoi, quels chiffres doivent clôturer le mois — et nous les écrivons tels qu'ils fonctionnent réellement aujourd'hui, pas tels que l'organigramme les décrit. Il en sort une liste de modules, une liste d'écarts et un plan par phases. La liste d'écarts sépare ce qu'Odoo standard fait déjà de ce qu'il ne fait pas, et c'est ce document qui décide du budget : il existe donc avant que quoi que ce soit ne soit développé.

• Les processus dans le périmètre, étape par étape, avec les rôles et les validations qui les traversent.
• Les applications standard qui les couvrent : Ventes, Achats, Inventaire, Fabrication, Comptabilité, Projet, RH, Site web.
• Les écarts répartis en trois : résolus par paramétrage, résolus par développement, ou résolus en changeant le processus.
• Les données à reprendre, et chaque système avec lequel Odoo doit échanger.
• Un plan par phases dont la première mise en production est assez réduite pour réellement avoir lieu.

Paramétrage

L'essentiel d'une implémentation est du paramétrage, réalisé dans une base dédiée qui préfigure la production : plan comptable, taxes et journaux, entrepôts et routes de stock, unités de mesure et variantes d'articles, listes de prix, séquences de numérotation, mises en page des documents, groupes d'utilisateurs et règles d'accès au niveau des enregistrements. Le module de localisation fiscale d'Odoo est installé et paramétré pour le pays depuis lequel vous facturez. Rien de tout cela n'est du code, et rien de tout cela ne casse à la version suivante.

Développement, uniquement en face de la liste d'écarts

Ce que le paramétrage n'atteint pas devient un module sur mesure, écrit en face des écarts validés au cadrage et relu avant la première ligne. Tout ce qui n'est pas sur cette liste est une demande de changement, avec sa propre décision et son propre chiffrage — pas un ajout discret au projet.

Reprise, recette et formation

Les données sont chargées dans une base de recette, puis les futurs utilisateurs testent leur propre travail sur leurs propres enregistrements : une vraie commande, une vraie livraison, une vraie clôture. Les problèmes trouvés là coûtent peu. La formation se fait sur cette même base, pour que personne ne soit formé sur une démonstration qui ne ressemble en rien à sa journée.

Mise en production et les semaines qui suivent

La bascule suit un plan écrit, avec un point de retour arrière et un décideur identifié. Les semaines qui suivent le démarrage décident si l'ERP est adopté ou contourné : elles font donc partie du projet, avec un point quotidien court, un backlog priorisé et les corrections qui n'apparaissent qu'une fois le volume réel dans le système.

Chaque ligne de code spécifique dans Odoo est une ligne que quelqu'un devra porter à la prochaine montée de version. C'est tout l'argument du paramétrage d'abord : bien paramétrés, les modules standard couvrent déjà la majeure partie de ce qu'une entreprise demande, et ce qu'ils couvrent ne coûte rien à maintenir.

L'ordre est donc fixe. Paramétrage, puis Odoo Studio pour les petites automatisations, les champs et les vues, puis un vrai module Python quand le besoin vous appartient réellement : une règle de prix que personne d'autre n'a, un document exigé par un régulateur, une machine ou une place de marché dont les connecteurs standard n'ont jamais entendu parler.

Ce que nous remettons en question

• Refaire un écran parce qu'il diffère de l'ancien logiciel, et non parce qu'il fonctionnerait mieux.
• Un processus spécifique qui ne survit que parce que personne ne l'a interrogé depuis le système précédent.
• Des rapports recréés champ par champ alors qu'un rapport standard et un filtre répondent à la même question.
• Personnaliser un module avant d'avoir passé un mois de travail réel dans sa version standard.

Comment le code spécifique est écrit

Le sur-mesure est livré sous forme d'addons Odoo en bonne et due forme : dépôt dédié, manifeste, une branche par version d'Odoo, et le cœur d'Odoo laissé intact. Les modèles sont étendus, jamais modifiés sur place. Les changements de schéma embarquent leurs scripts de migration dans le module, les règles métier sont couvertes par des tests, et le module est documenté assez précisément pour que la montée de version suivante soit une relecture et non une fouille archéologique.

Le type de module dont il s'agit en général

• Une règle de prix, de remise ou de commission que les listes de prix standard n'expriment pas.
• Une étape de validation liée à vos propres seuils, rôles et documents.
• Un document — facture, bon de livraison, certificat, étiquette — dans une mise en page imposée par un client ou un régulateur.
• Un connecteur vers un système sans application Odoo standard : une place de marché, un transporteur, un format bancaire, une machine.
• Un champ calculé ou un rapport qui pilote l'activité et dont Odoo n'a aucune notion.
• Un import ou un export dans un format exigé par un partenaire, planifié et doté d'un chemin d'erreur visible.

Chaque module arrive avec les mêmes éléments : les modèles qu'il touche, les tests qui le couvrent, une note sur ce qu'il demandera à la prochaine version majeure, et le dépôt dans lequel il vit — le vôtre, pour que changer de prestataire reste une décision et non une reconstruction.

C'est sur la reprise de données que les projets ERP échouent en silence. La règle est simple : chaque objet est repris volontairement, rapproché d'un chiffre auquel votre comptabilité fait déjà confiance, et validé avant de compter.

Ce qui est repris, et dans quel ordre

• Les données de base d'abord — tiers et contacts, articles et variantes, unités de mesure, nomenclatures, listes de prix.
• Les soldes ensuite — factures clients et fournisseurs ouvertes, stock initial par emplacement et par lot, à-nouveaux comptables.
• L'historique seulement quand il le mérite : les documents clos sont souvent mieux consultables dans l'ancien système qu'à moitié importés dans le nouveau.
• Chaque chargement passe d'abord en recette, et deux fois : c'est le second passage qui prouve que le premier était reproductible.

Rapprochement avant validation

Chargé ne veut pas dire repris. Valorisation du stock, créances, dettes et balance générale sont comparées au système source et expliquées jusqu'à ce que l'écart soit nul ou compris. Les doublons de tiers, les codes de taxe manquants et les références mortes remontent à ce moment-là — c'est précisément pour cela que le nettoyage se fait avant le week-end de bascule, et non pendant.

Démarrer par étapes

Quand l'activité le permet, les modules démarrent par groupes plutôt qu'en une seule bascule nocturne. Ventes, achats et inventaire peuvent tourner d'abord pendant que la comptabilité clôture encore l'exercice dans l'ancien système ; la fabrication suit une fois le stock fiable. Un démarrage par étapes donne à chaque équipe une semaine normale pour apprendre une chose, au lieu d'une semaine anormale pour tout apprendre.

Formation et transfert

Les utilisateurs clés sont formés sur votre paramétrage et vos données, pas sur une base de démonstration, et ils forment les autres. Vous recevez des procédures écrites par rôle dans la langue dans laquelle vos équipes travaillent vraiment — français, anglais ou arabe — et avec elles le transfert technique : dépôts, documentation des modules, accès à la base et aux sauvegardes, et la liste ouverte de ce qui reste à décider. Un bon transfert se mesure à une chose : vous pouvez exploiter le système sans nous.

Une intégration Odoo relie l'ERP à un système qui détient des données qu'Odoo n'a pas : une boutique en ligne, un prestataire de paiement, un transporteur, une banque, une machine, une application historique. Odoo expose ses modèles en XML-RPC et JSON-RPC, et un module sur mesure peut ajouter des points d'entrée REST, des webhooks et des tâches planifiées. La question n'est donc presque jamais de savoir si deux systèmes peuvent communiquer, mais qui est propriétaire de quel enregistrement, et ce qui se passe quand l'un des deux est indisponible.

Connexions courantes

• E-commerce : le site d'Odoo lui-même, ou Shopify ou WooCommerce en vitrine avec Odoo qui tient le stock et la facturation.
• Paiement et banque : passerelles côté vente, import et rapprochement des relevés côté comptabilité.
• Transport et logistique : étiquettes transporteur, suivi réécrit sur le bon de livraison, terminaux code-barres et matériel d'entrepôt.
• Outils métier : CRM, messagerie, tableurs, BI et API internes — orchestrés dans n8n quand le besoin est un flux de travail plutôt qu'une fonctionnalité produit.
• Industriel : automates, balances, imprimantes d'étiquettes et données machine, où le réseau de l'atelier contraint la conception autant que le logiciel.

Ce qui fait tenir une intégration dans la durée

• Un seul système de référence par champ, écrit noir sur blanc, pour que rien ne soit modifié des deux côtés.
• Des écritures idempotentes et des identifiants externes stockés, pour qu'une relance ne crée jamais une deuxième commande.
• Des tâches en file avec relances et file d'échec, plutôt que des appels synchrones qui figent l'écran d'un utilisateur.
• Un journal lisible par une personne non développeuse, et une alerte quand un flux s'arrête — plutôt qu'un silence que personne ne remarque pendant une semaine.
• Un environnement de recette branché sur le bac à sable du prestataire, pour éprouver l'intégration avant qu'elle ne touche de l'argent réel.

Odoo contient déjà la trace de presque tout ce que fait l'entreprise, ce qui en fait le bon endroit pour de l'automatisation et le mauvais endroit pour un agent conversationnel. Le périmètre est volontairement étroit : un modèle lit quelque chose de non structuré, un enregistrement Odoo en est créé, et une personne le valide avant qu'il ne compte.

À quoi cela ressemble concrètement

• Factures fournisseurs et bons de livraison lus vers des factures fournisseurs en brouillon, lignes rapprochées des articles et des commandes d'achat, laissées en brouillon pour la comptabilité.
• E-mails entrants et demandes web classés, orientés et rattachés au bon tiers ou à la bonne piste, au lieu d'être transférés à la main.
• Réponses de premier niveau rédigées à partir de vos propres documents et de vos tickets passés, qu'une personne envoie, corrige ou écarte.
• Descriptions produits et fiches techniques rédigées à partir de données structurées, relues avant publication.
• Le texte libre que personne n'exploite — commentaires de commande, remarques qualité, journaux de maintenance — transformé en champs filtrables et exploitables en rapport.

Comment c'est construit

Sous forme de module Odoo, pas d'application greffée à côté. L'appel au modèle est placé derrière une action serveur ou une tâche planifiée, sa sortie est écrite dans de vrais champs sur de vrais modèles, et les règles d'accès d'Odoo s'appliquent comme partout ailleurs. Quand un flux traverse plusieurs systèmes, il tourne dans n8n et réécrit via l'API.

• Chaque exécution laisse un journal : ce qui est entré, ce qui est revenu, et quel enregistrement a été touché.
• Rien ne se valide tout seul. Les documents arrivent en brouillon et une personne les confirme.
• Un plafond de coût par traitement et un chemin de relance, pour qu'une mauvaise journée chez un fournisseur ne devienne pas la vôtre.
• En cas d'échec, on retombe sur « une personne le fait », jamais sur un enregistrement faux écrit en silence.

Ce que nous refusons : une automatisation qui comptabilise une écriture que personne n'a relue, et tout ce qui doit être juste à chaque fois sans moyen de s'apercevoir que ça ne l'est plus.

L'application de fabrication d'Odoo couvre les nomenclatures, les postes de charge et les gammes, les ordres de travail et la sous-traitance, au-dessus du même moteur d'inventaire qui gère réceptions, livraisons et valorisation des stocks. Le contrôle qualité et la maintenance sont des applications à part, et Qualité n'existe qu'en Enterprise. Pour une PME ou une ETI industrielle, cela suffit généralement en standard. Ce qui prend du temps, c'est de décrire l'atelier avec exactitude — pas d'écrire du code.

Là où le travail se trouve vraiment

• Des nomenclatures conformes à la réalité, variantes, nomenclatures fantômes, rebuts et sous-produits compris.
• Des gammes et des postes de charge dont les capacités et les coûts veulent dire quelque chose, puisqu'ils pilotent l'ordonnancement et la marge.
• Le réapprovisionnement : règles de stock, délais, fabrication à la commande ou sur stock, et routes multi-étapes pour la réception, la qualité et le rangement.
• La traçabilité : lots et numéros de série choisis délibérément, parce qu'ils décident si un rappel prend un après-midi ou un mois.
• La réalité de l'atelier : lecture de codes-barres, ordres de travail sur tablette, et des étapes que les opérateurs suivront réellement.
• Les coûts : coût standard ou coût moyen, et une comptabilité analytique qui montre la marge par affaire plutôt que par exercice.

Là où le sur-mesure se justifie

L'intégration des machines et des balances, une règle d'ordonnancement propre à votre site, une étiquette ou un format EDI imposé par un client, et des documents qualité qu'un régulateur veut sous une forme précise. Ce sont de vrais écarts. Un écran d'ordre de travail qui ressemble simplement à l'ancien n'en est pas un.

L'endroit où tourne Odoo décide de ce que vous pouvez développer, de qui porte l'exploitation, et de ce que sera une montée de version. Autant le décider volontairement et tôt : changer plus tard est un projet en soi.

Odoo Online

Odoo exploite la plateforme, vous la paramétrez. Les personnalisations Studio passent ; les modules Python sur mesure, non, et il n'y a ni accès shell ni accès à la base. C'est la bonne réponse pour une entreprise qui restera dans Odoo standard — et la mauvaise dès que la liste d'écarts contient du code.

Odoo.sh

La plateforme d'Odoo pour héberger Odoo avec votre propre code : adossée à git, avec des branches de développement et de staging, un build à chaque push, des sauvegardes et un chemin supporté pour les montées de version. C'est là que se placent la plupart des implémentations comportant du développement, parce que les développeurs y retrouvent un vrai flux de travail sans que vous ayez à exploiter des serveurs.

Auto-hébergement

Votre propre infrastructure, ou un cloud européen que vous choisissez. C'est la bonne réponse quand la localisation des données, une intégration sur site ou une équipe plateforme déjà en place l'exigent. En échange, vous portez le réglage de PostgreSQL, les sauvegardes et les répétitions de restauration, la supervision, la gestion du filestore et la mécanique des montées de version. C'est un vrai métier d'exploitation : dotez-le, ou prenez Odoo.sh.

L'édition est une question distincte de l'hébergement. Community suffit pour un usage léger et auto-hébergé ; Enterprise apporte les modules, les applications mobiles et Studio dont la plupart des entreprises finissent par avoir envie. Dans les deux cas, la licence est un contrat entre vous et Odoo : nous implémentons, nous ne la revendons pas, et nous n'avons aucun intérêt commercial dans l'édition que vous retiendrez.

Odoo publie une version majeure par an et n'en maintient qu'un nombre limité : un déploiement Odoo n'est donc jamais terminé, il est entretenu. Que vous démarriez sur Odoo 18 ou sur la version courante, planifiez la première montée de version avant la mise en production, et non le jour où le support s'arrête.

Ce qu'une montée de version implique réellement

• Le paramétrage et les données standard sont pris en charge par le parcours de migration d'Odoo et se déplacent en général sans drame.
• Les modules sur mesure sont le vrai travail : API dépréciées, champs renommés, héritages de vues modifiés et modèles déplacés doivent tous être relus et adaptés.
• Les applications tierces avancent au rythme de leur auteur, ce qui est une raison de traiter chaque application installée comme une dépendance avant de l'installer.
• Les intégrations sont re-testées sur la nouvelle version, parce qu'un champ renommé casse un connecteur en silence.
• L'ensemble de la montée de version est répété sur une copie de la production et validé par les mêmes utilisateurs clés qui ont validé le démarrage.

C'est le coût honnête de chaque personnalisation, et la raison pour laquelle la liste d'écarts compte plus que la liste de fonctionnalités. Un déploiement resté proche du standard traite une montée de version comme une relecture. Un déploiement qui traîne des années de code spécifique jamais relu se transforme en réimplémentation — c'est ainsi que des entreprises se retrouvent bloquées plusieurs versions en arrière.