Saff Palm

Une huilerie de palme reçoit sa matière première par petits camions, toute la journée, souvent de producteurs sans structure commerciale. Le circuit standard d’un ERP — bon de commande, puis réception, puis facture — suppose qu’on connaisse le fournisseur et la quantité avant qu’il n’arrive. Ici c’est l’inverse : le camion se présente, on pèse, et c’est la pesée qui crée la transaction.

Le pont-bascule existait, avec son logiciel dédié et sa propre base de données. Personne ne songeait à le remplacer — mais rien ne remontait de lui vers l’ERP. Chaque pesée était retapée.

Plus loin dans l’usine, la production se suivait sur un cahier de quart papier : stérilisation, extraction, clarification, chaudière, laboratoire, maintenance, purge, stockage silo. Chaque poste, chaque équipe de jour et de nuit, remplissait son feuillet. Ces feuillets ne se consolidaient nulle part. Personne ne pouvait dire, le matin, quel taux d’extraction la nuit avait produit — alors que c’est l’indicateur qui gouverne toute la rentabilité du métier.

Deux décisions structurent le projet.

La première : lire le logiciel de pesée là où il écrit déjà. Plutôt que de remplacer un outil qui fonctionne, ou de demander à son éditeur une passerelle, un agent installé sur le poste de pesée lit directement la base du logiciel et pousse les pesées dans Odoo. L’ERP ne touche jamais la base propriétaire, et le poste de pesée continue de travailler exactement comme avant.

La seconde : refuser le MRP. Un module de fabrication standard aurait imposé des nomenclatures et des ordres de travail à un procédé continu qui n’en a pas — on ne fabrique pas un lot d’huile, on fait tourner une chaîne. L’option a été ouverte puis écartée. Le suivi de production reproduit ce que l’usine faisait déjà : le cahier de quart, poste par poste, quart par quart — mais numérique, et consolidé automatiquement.

Le reste tient en surcharges ponctuelles de modèles standard, une par besoin, sans module fourre-tout.

Douze modules sur mesure sur Odoo 19.

La pesée devient le point d’entrée unique : un ticket de pesée engendre directement soit une réception avec son mouvement de stock et sa facture fournisseur, soit une vente — sans les trois validations successives que le standard exige. Les nombreux petits apporteurs passent par des partenaires génériques plutôt que d’encombrer le fichier tiers.

Le cahier de quart couvre les huit postes de l’usine. Les fiches partagent une même mécanique d’état et de workflow au lieu d’être redéveloppées une par une. Une vue SQL agrège chaque jour, par société, les fiches des deux quarts et en dérive les indicateurs qui comptent : tonnage de graines traitées, palmiste produit, et le taux d’extraction d’huile. Aucun seuil n’est écrit en dur — la cible de rendement, le rendement plancher, la durée d’arrêt tolérée sont des paramètres. Un écart déclenche une alerte qui arrive dans le fil de discussion des personnes concernées.

Le décisionnel repose sur un moteur maison plutôt que sur un outil externe. Les indicateurs sont des requêtes SQL, mais exécutées sous contrainte stricte : transaction en lecture seule, délai d’exécution borné, validation de la requête par liste blanche, cloisonnement des données par utilisateur. Le tout est couvert par des tests dédiés. Par-dessus ce moteur, un tableau de bord « Pilotage Huile de Palme » croise cinq filtres et une dizaine d’indicateurs : réceptions de graines, top fournisseurs, transformation graines → huile, rendement mensuel, stock silo, chiffre d’affaires par produit, alertes par atelier.

La comptabilité sort aux normes SYSCOHADA, avec facture agrégée et reçu de paiement adaptés aux usages locaux.

Les pesées entrent seules, et ne peuvent pas entrer deux fois : chaque ligne lue est empreintée, et n’est réécrite que si elle a réellement changé. Un camion se transforme en réception, mouvement de stock et facture en une opération au lieu de trois. Le cahier de quart est saisi une fois et se consolide tout seul : le taux d’extraction de la veille existe le matin, sans que personne ne l’ait calculé. Et les écarts se signalent d’eux-mêmes au lieu d’être découverts en fin de mois.

Le projet a suivi la montée de version d’Odoo 18 vers Odoo 19, avec ses scripts de migration versionnés — le système est maintenu, pas livré puis abandonné.