Sutec / Café Continent

Chez un transformateur de cacao, tout se joue à la réception. Le camion passe au pont-bascule, on note un poids, on prélève un échantillon, le laboratoire mesure l’humidité et les réfractions — matière étrangère, brisures, déchets — et de ces chiffres dépend le prix payé au producteur comme la décision d’accepter ou de refouler le chargement.

Chacune de ces étapes existait, mais aucune ne parlait à la suivante. La pesée vivait d’un côté, l’analyse de laboratoire de l’autre, l’ordre d’usinage encore ailleurs. Rien ne reliait un lot entré à un lot sorti. Entre les deux sociétés du groupe, les documents se recopiaient à la main. Et la certification électronique des factures, devenue obligatoire en Côte d’Ivoire, se faisait hors de l’ERP.

Le parti pris est resté le même du début à la fin : ne pas remplacer ce que le standard fait déjà bien. Achats, stock, fabrication, comptabilité et point de vente restent du Odoo natif. Les restrictions métier — qui peut créer un article, qui peut confirmer une vente, qui voit une analyse validée — sont posées en groupes et règles d’enregistrement, pas en code de contrôle.

Le sur-mesure ne commence que là où le métier du cacao n’a pas d’équivalent standard. La pesée, l’analyse qualité et la division de lot sont de vrais nouveaux modèles ; tout le reste s’ajoute par héritage aux flux existants, sans les détourner.

Un exemple de cet état d’esprit : les ordres de fabrication en usinage à façon devaient retrouver leur donneur d’ordre. La première version cherchait le partenaire par son nom — sauf que deux partenaires portaient le même, dont un archivé. La résolution passe désormais par l’historique réel du flux, et s’abstient explicitement quand le résultat est ambigu, plutôt que de désigner le mauvais client.

Dix-neuf modules sur mesure sur une instance Odoo 18 Enterprise partagée par les deux sociétés du groupe.

Le socle métier relie la chaîne complète : le ticket de pesée porte les poids d’entrée, de sortie et net, l’humidité, les réfractions et la décision d’acceptation ; l’analyse de laboratoire est rattachée à la réception puis à l’ordre de fabrication qu’elle alimente ; la division de lot suit la matière au-delà de la traçabilité native. Les tickets peuvent être injectés depuis le poste de pesée par un point d’entrée HTTP dédié, protégé par jeton — le serveur recalculant lui-même l’état du ticket plutôt que de faire confiance à ce qu’on lui envoie.

La conformité fiscale est traitée dans l’ERP : factures, avoirs et bordereaux d’achat aux producteurs sont certifiés FNE directement depuis la comptabilité et depuis la caisse.

Le décisionnel fonctionne dans les deux sens. Odoo expose ses données à Power BI par une API gouvernée — clé d’accès, quota d’appels, liste blanche d’adresses, journalisation — au lieu d’ouvrir la base en lecture. Et dans l’autre sens, la validation d’une facture déclenche le rafraîchissement des rapports Power BI, via une authentification OAuth2 Azure AD.

Le reste du périmètre couvre les droits d’accès au niveau du champ, du bouton et du menu — bien plus fin que les groupes standard —, la duplication tracée de documents entre les deux sociétés, une piste d’audit générique, et l’export de la balance générale au format attendu par le cabinet comptable.

La chaîne réception → analyse → usinage → export tient dans un seul système, et un lot se suit d’un bout à l’autre. Les pesées entrent dans l’ERP comme des enregistrements structurés plutôt que d’être ressaisies. Les documents qui passent d’une société à l’autre laissent une trace au lieu d’être recopiés. Les factures sortent certifiées. Et les tableaux de bord de direction se rafraîchissent quand la comptabilité bouge, pas à heure fixe.