ERP Odoo sur mesure pour un fabricant de fermetures métalliques

Deux instances sur infrastructure maîtrisée

Chaque société dispose de sa propre instance Odoo 19 Enterprise, hébergée sur un serveur dédié.

Une chaîne d'intégration continue construit et teste l'image applicative à chaque modification ; le déploiement reste une opération manuelle et contrôlée, faute de route réseau entre les exécuteurs mutualisés et le serveur.

Vingt-et-un modules pour couvrir la chaîne complète

Le périmètre couvre le cycle entier : relation client, ventes, achats, stock, fabrication, service après-vente, comptabilité, signature électronique, gestion documentaire et codes-barres.

Sur le cycle de vente, le point dur était la maîtrise du risque client. Le paramétrage bloque désormais l'émission d'un accusé de réception lorsque l'encours dépasse le plafond autorisé — un encours élargi à toutes les commandes non annulées, brouillons compris, et pas seulement aux commandes confirmées. Le déblocage passe par un superviseur, avec un double verrou empêchant le contournement. Un montant minimum de commande bloque les devis trop faibles dès l'envoi au client. Les conditions de paiement acceptées sont paramétrables : tout ce qui suppose un acompte à sécuriser bloque la validation.

Sur les achats, le rapprochement se fait en trois voies — commande, réception, facture — avec un seuil de tolérance d'écart paramétrable. Le seuil de franco de port du fournisseur s'affiche directement sur le bon de commande pendant la saisie, et non plus après coup.

Sur le stock et la fabrication, cinq zones physiques ont été modélisées, les produits finis sont suivis au numéro de série avec la règle « un ordre de fabrication, un numéro de série », les articles sont étiquetés au format standard et la saisie se fait au terminal mobile.

Sur le service après-vente, les tickets s'ouvrent par téléphone ou par une adresse mail dédiée, s'identifient par numéro de commande, et tracent le temps passé, les ordres de fabrication supplémentaires et les matières perdues.

Côté comptabilité, l'outil externe reste maître du dossier ; Odoo lui transmet factures et avoirs par interface, et produit le fichier des écritures comptables réglementaire.

Des garde-fous qui travaillent tout seuls

Une douzaine d'automatisations tiennent les règles de gestion à la place des utilisateurs : blocage de l'accusé de réception au-delà de l'encours autorisé, refus des devis sous le montant minimum dès leur envoi, alerte quand une assurance client arrive à échéance, signalement au pôle ordonnancement dès qu'un devis est signé, message de traçabilité quand un bon de commande passe sous le franco fournisseur, alerte sur les écarts d'inventaire. Le principe est constant : la règle métier vit dans le système, pas dans la mémoire de celui qui saisit.

Trente-et-une décisions tranchées et tracées

Chaque arbitrage — architecture comptable, qui peut émettre un accusé de réception, qui voit la marge, comment se calcule l'encours, faut-il tracer les numéros de série — a été discuté en atelier, tranché, daté et consigné. Certaines décisions ont été révisées en cours de route : elles portent la trace de leur révision plutôt qu'une réécriture silencieuse.

Un exemple de ce que cette rigueur permet d'attraper : des règles de restriction avaient été posées sur un groupe de sécurité natif d'Odoo, partagé implicitement. Résultat, tout membre de ce groupe — y compris l'administrateur — se retrouvait bloqué sur les mouvements de stock, incapable de confirmer une commande. La correction n'a pas consisté à ajouter une exception, mais à créer un groupe métier dédié et à y reporter les règles. La leçon a été inscrite comme règle générale du projet : ne jamais poser de règle restrictive sur un groupe natif partagé.