Aller au contenu
Twinautomate — Systèmes métier. Données. Décision.

Distributeur alimentaire

Une PME de distribution alimentaire pilotait ses commandes, ses achats et ses marges depuis plusieurs fichiers Excel, WhatsApp et MyUnisoft. Le projet est livré : une application métier qui pilote trésorerie, clients et fournisseurs — et relie Odoo et MyUnisoft.
Phare éclairant la nuit, guidant la navigation

« On nous a donné des fichiers Excel. Derrière, il y avait toute une entreprise. »

01 · Le point de départ

Tout est parti d’un problème beaucoup plus petit

Ce projet n’a pas commencé par un cahier des charges. Il a commencé par une demande simple, presque discrète : mieux comprendre les paiements.

Concrètement : savoir ce qui reste à payer aux fournisseurs, ce qui reste à encaisser des clients, suivre les achats et retrouver une visibilité financière claire. Pas de refonte générale, pas de grand vocabulaire de transformation — une entreprise qui veut simplement y voir clair.

Pour répondre à cette question, il fallait comprendre d’où venaient les informations. Nous avons donc demandé à voir les fichiers. C’est là que tout a commencé.

02 · La découverte

Puis nous avons ouvert les fichiers

Derrière la demande initiale, nous avons trouvé le quotidien complet d’une PME de distribution alimentaire. Les commandes arrivent par WhatsApp, par téléphone, parfois par email. Les prix vivent dans des tableurs. Les factures partent d’Excel en PDF. La comptabilité est tenue dans MyUnisoft. Et les paiements, les rapprochements et les échéances se suivent à la main, dans des tableaux et des mémoires.

Un fichier concentre une grande partie de l’activité : LISTE ACHAT RUNGIS.xlsx, environ 28 onglets.

À côté, un deuxième fichier pilote toute la politique de prix : Listing des prix.xlsx, plus de 1 600 références produits — codes, libellés, conditionnements, TVA, prix d’achat, prix de vente, prix HT et TTC, marges, commentaires, et parfois des références propres à certains clients. Des milliers de lignes et de formules, ajustées au fil des arrivages et des marchés.

Et en arrière-plan, les exports comptables de MyUnisoft : environ 6 500 écritures sur les comptes fournisseurs et clients, que nous avons analysées pour comprendre les flux réels — et croiser avec ce que les fichiers racontent.

~28
Onglets dans le fichier d’achats
1 600+
Références produits dans le listing des prix
~6 500
Écritures comptables analysées (MyUnisoft)
3
Canaux de commande — WhatsApp, téléphone, email

Ce que couvrent les onglets du fichier d’achats :

  • Commandes restaurants
  • Consolidation des commandes
  • Préparation des achats
  • Bons de commande personnalisés
  • Fournisseurs
  • Stocks
  • Tarifs
  • Production
  • Préparation
  • Tournées
  • Planning

03 · Le constat

Excel n’était pas le problème

Après cette lecture, la tentation est grande de conclure : « trop d’Excel, il faut tout remplacer ». Ce serait passer à côté de l’essentiel.

Ces fichiers contiennent déjà le métier : des règles, des habitudes, des exceptions, une logique opérationnelle affinée depuis des années. Comment consolider des commandes hétérogènes, préparer les achats, appliquer le bon prix à chaque client, calculer une marge quand les cours bougent. Ce savoir est là, écrit dans des cellules, amendé saison après saison.

Le problème n’est pas le contenu : c’est sa forme. Tout est réparti entre plusieurs fichiers et plusieurs canaux ; chaque recopie manuelle est une occasion d’erreur ; et rien de tout cela ne se partage sereinement entre les personnes. L’information existe — elle ne circule pas.

Excel n’est pas forcément le problème. Il contient souvent déjà le prototype du futur logiciel métier.

04 · La chaîne métier

Une commande déclenche beaucoup plus qu’une ligne Excel

Pour savoir ce que l’application devait devenir, nous avons suivi le chemin réel d’une commande — depuis le message WhatsApp d’un restaurant jusqu’à la marge constatée en comptabilité. Une seule ligne de commande traverse en réalité toute cette chaîne :

  1. 01

    Commande restaurant

    Par WhatsApp, téléphone ou email

  2. 02

    Consolidation

    Toutes les commandes réunies dans le fichier

  3. 03

    Stock

    Ce qui est disponible, ce qui manque

  4. 04

    Décision d’achat

    Ce qu’il faut acheter, et pour qui

  5. 05

    Sourcing fournisseur

    Saison, qualité, origine, prix du marché, arrivages, spécialistes

  6. 06

    Achat

    Auprès du bon fournisseur, au bon moment

  7. 07

    Réception

    Les marchandises arrivent et sont contrôlées

  8. 08

    Préparation

    Les commandes sont préparées

  9. 09

    Livraison

    Les tournées partent vers les restaurants

  10. 10

    Prix

    Le bon prix appliqué à chaque produit, à chaque client

  11. 11

    Facturation

    Aujourd’hui depuis Excel, en PDF

  12. 12

    Comptabilité

    Les écritures alimentent MyUnisoft

  13. 13

    Paiement

    Virement, chèque, carte ou espèces

  14. 14

    Rapprochement

    Les paiements rapprochés des factures, à la main

  15. 15

    Trésorerie

    Ce qui reste à encaisser, ce qui reste à payer

  16. 16

    Marge

    La réalité économique de l’activité, enfin visible

Aujourd’hui, cette chaîne traverse des fichiers Excel, WhatsApp, le téléphone, l’email, des factures PDF, MyUnisoft et des suivis manuels — avec une recopie à chaque frontière. C’est exactement ce chemin que le projet devait réunir : les mêmes données, de la commande jusqu’à la marge.

05 · Les itérations

Le fichier ne disait pas tout

Très vite, les premières analyses ont révélé des zones floues : des colonnes sans libellé, des onglets qui se recouvrent, des choix d’achat impossibles à déduire des seules données. Le fichier disait ce qui avait été fait — pas pourquoi.

Nous avons donc procédé par itérations, et c’est encore ainsi que le projet a avancé : une passe d’analyse, des questions, une réponse métier, une compréhension affinée — puis une nouvelle itération. Chaque passage éclaircit une zone, valide une règle, corrige une hypothèse mal comprise.

  • Analyse
  • Questions
  • Réponse métier
  • Nouvelle compréhension
  • Nouvelle itération

La boucle se referme : chaque nouvelle itération repart d’une analyse.

Quelques exemples de ce que les fichiers ne pouvaient pas nous dire seuls :

  • La saisonnalité

    Ce qui est acheté, à quel fournisseur et à quel prix dépend de la saison. Le fichier le reflète, mais ne l’explique pas.

  • La substitution de produits

    Un produit manquant peut être remplacé par un équivalent : l’équivalence est un savoir d’acheteur, pas une donnée.

  • Les fournisseurs spécialisés

    Certains produits ne s’achètent que chez certains fournisseurs, selon l’origine, la qualité ou l’arrivage.

  • L’arbitrage des paiements

    Qui payer en premier, avec quels encaissements en attente : des arbitrages suivis humainement au quotidien.

  • Les échéances fournisseurs

    Les dates, les reports et les exceptions vivaient dans des suivis manuels et dans des mémoires.

  • La connaissance portée par les personnes

    Une partie de la logique n’est écrite nulle part : elle vit dans la tête de quelques personnes clés.

Deux ambiguïtés réelles, trouvées dans les fichiers, qui ont changé la conception :

Un code produit, huit origines

Dans le listing, un même code désignait huit mangues d’origines différentes — chacune à son prix d’achat. Concevoir le produit comme une simple liste aurait fusionné des produits commerciaux distincts : origine et transport sont devenus des variantes à part entière, jamais fusionnées automatiquement.

Un même nom, deux entreprises

Un même nom commercial désignait deux entreprises réelles, deux SIRET distincts. La réconciliation a été conçue en conséquence : le nom seul ne fait jamais un rapprochement, un SIRET partagé reste une ambiguïté — et aucune fusion n’est automatique.

C’est précisément ce savoir-là que l’application devait absorber, étape après étape — sans lui, elle n’aurait rien remplacé.

06 · La méthode

Nous n’avons donc pas commencé à coder tout de suite

Avec un tel écart entre ce que montraient les fichiers et ce qui se passait réellement, coder immédiatement aurait figé des malentendus dans du logiciel. Avant de construire, il fallait comprendre le vrai fonctionnement — et le structurer.

Nous avons donc commencé par poser les fondations, domaine par domaine :

  • Produits
  • Clients
  • Fournisseurs
  • Commandes
  • Achats
  • Sourcing
  • Prix
  • Marges
  • Facturation
  • Paiements
  • Trésorerie
  • Remplacer MyUnisoft

    La comptabilité reste où elle est. L’application consomme ses exports, réconcilie au centime — et n’y écrit jamais.

  • Refaire un ERP générique

    Pas de modules standard à subir : l’outil épouse le fonctionnement réel de cette entreprise.

  • Dupliquer ce qui marche déjà

    Si un logiciel fait bien son travail, nous n’y touchons pas : l’application relie, elle ne duplique pas.

Le but est plus précis : créer l’outil métier qui décide et relie — l’application pilote les encours et la trésorerie, Odoo exécute le transactionnel, MyUnisoft certifie la comptabilité.

Espace « Qualité & imports » de l’application : import contrôlé des exports grand livre MyUnisoft, historique immuable des imports, réconciliation Tiers ↔ comptes comptables avec propositions expliquées et aucune fusion automatique (données de démonstration).
Les fondations, telles qu’elles existent aujourd’hui : les exports MyUnisoft entrent par un pipeline contrôlé — aperçu avant toute écriture, empreinte du fichier, doublon refusé — et la réconciliation propose sans jamais fusionner en silence.

07 · Ce que l’application est devenue

Ce que l’application est devenue

L’application livrée est un poste de pilotage financier et fournisseur. Elle n’est ni un ERP, ni un substitut à la comptabilité : elle décide et relie. Voici ce qui a été construit, tel qu’il existe aujourd’hui.

  • Cockpit & position prévisionnelle

    La trajectoire de trésorerie sur 30 à 90 jours : encaissements projetés, sorties fournisseurs, engagements déclarés — et un point bas signalé avant d’arriver, là où les exports mensuels arrivaient trop tard pour décider.

  • À recevoir — créances clients

    Ce que chaque client doit, facture par facture : retards, échéance du jour, à venir, sans date — avec la provenance de chaque date. Le suivi qui vivait dans les têtes et dans des exports retraités à la main.

  • À payer — dettes fournisseurs

    La dette nette réelle, présentée séparément des documents actifs et des mouvements non documentaires ; chaque fournisseur qualifié par criticité (bloque-t-il l’approvisionnement ?) et souplesse (peut-il attendre ?).

  • Intentions de paiement

    « Je prévois de payer X € à telle date sur telles factures » : la décision est tracée, plafonnée au réel, et toujours distincte de l’échéance — la projection n’invente jamais un paiement.

  • Liquidité déclarée & engagements

    Le montant réellement mobilisable, déclaré par le dirigeant avec son périmètre, et l’historique des époques jamais réécrit. L’application refuse de transformer une déclaration en « solde bancaire certifié ».

  • Échéances & règles

    Une date par document, avec sa provenance : date source, règle du fournisseur (30 jours date de facture…) ou saisie humaine tracée. Avant, les échéances n’existaient nulle part.

  • Réconciliation Tiers ↔ comptes

    Les comptes 401/411 rattachés aux vrais tiers métier, avec des propositions expliquées : le moteur propose, le dirigeant décide, rien ne fusionne jamais en silence.

  • Qualité & imports

    Les exports MyUnisoft entrent par un pipeline contrôlé : aperçu avant écriture, empreinte du fichier, doublon refusé, totaux réconciliés au centime. La comptabilité reste en lecture seule.

  • Application de poste

    Un logiciel desktop (macOS et Windows) qui héberge ses données localement, relie plusieurs postes en réseau local chiffré, avec trois rôles — dirigeant, suivi fournisseurs, acheteur —, sauvegardes automatiques et écran de diagnostic.

Cockpit de l’application métier : position commerciale prévisionnelle (liquidité déclarée, fin d’horizon, point bas), trajectoire sur 90 jours, alertes, encours à recevoir et à payer, intentions et engagements (données de démonstration).
Le cockpit : la vue que le dirigeant ouvre pour décider — position prévisionnelle, trajectoire, alertes, encours et intentions réunis.
Espace « À recevoir » de l’application : encours client réel, créances facture par facture avec état (en retard, dû aujourd’hui, à venir, non daté), provenance des échéances, exposition par client (données de démonstration).
À recevoir : savoir ce qu’on nous doit, facture par facture.
Espace « À payer » de l’application : dette fournisseur nette réelle, documents actifs observés, mouvements non documentaires, échéances, criticité et souplesse par fournisseur, exceptions (données de démonstration).
À payer : l’arbitrage des paiements posé sur des critères explicites.
Espace « Liquidité » de l’application : déclaration de liquidité mobilisable avec périmètre explicite, avertissement « pas un solde bancaire certifié », historique des époques jamais réécrit, engagements connus (données de démonstration).
Liquidité : une déclaration humaine avec périmètre explicite et historique d’époques — jamais un solde reconstruit.

Captures réelles de l’application livrée (v1.0), en mode démonstration — données fictives.

Résultats : ce que nous pouvons démontrer.

Le projet est terminé — et nous ne publierons toujours pas de « +30 % de productivité » : les mesures de temps envisagées au départ n’ont pas été instrumentées, et nous préférons retirer une promesse plutôt que de l’inventer. Voici ce qui est établi, par la conception de l’outil et par les tests menés sur les vrais fichiers de l’entreprise.

4 100+
Documents comptables suivis un par un — contre des totaux globaux auparavant
Au centime
Totaux des exports réconciliés entre MyUnisoft et l’application, vérifiés par tests
0
Écriture comptable modifiée — l’application reste en lecture seule sur la comptabilité

Ce qui a changé dans le fonctionnement quotidien :

  • Ce qui reste à encaisser et ce qui reste à payer est visible facture par facture, avec les retards — auparavant réparti entre exports mensuels et mémoire des personnes.
  • L’arbitrage des paiements fournisseurs s’appuie sur des critères explicites : criticité, souplesse, trésorerie projetée — plus uniquement sur la pression du moment.
  • Un point bas de trésorerie est anticipé par la trajectoire, au lieu d’être découvert après coup.
  • Les échéances, qui n’existaient nulle part, portent désormais une date documentée et sa provenance.
  • Le savoir d’arbitrage — fournisseurs prioritaires, fournisseurs souples, échéanciers — est formalisé dans l’outil et partageable, plus seulement porté par quelques têtes.
  • La séparation est claire : l’application métier décide et relie, Odoo exécute le transactionnel, MyUnisoft certifie la comptabilité.

La transformation, en quatre regards :

Où était l’information

Avant — Répartie entre environ 28 onglets, WhatsApp, MyUnisoft et la mémoire des personnes.

Après — Un référentiel unique, alimenté par des imports contrôlés, traçables et refusés en cas de doublon.

Les échéances

Avant — Nulle part : gardées en tête, compensées par un lettrage manuel compte par compte.

Après — Une date par document, avec sa provenance — source réelle, règle du fournisseur ou saisie tracée.

La décision de paiement

Avant — Arbitrage sous pression, après la journée de travail, à partir d’exports mensuels retraités à la main.

Après — Trajectoire prévisionnelle, intentions de paiement tracées, fournisseurs qualifiés par criticité et souplesse.

Les frontières du système

Avant — Quatre univers sans identifiant commun : fichiers Excel, messageries, comptabilité, têtes.

Après — Frontières explicites : l’application métier décide et relie, Odoo exécute, MyUnisoft certifie.

Chaque point ci-dessus est un fait de conception ou un résultat de test sur les fichiers réels — pas une estimation de gain.

09 · Ce que nous en retenons

Ce que ce projet nous apprend sur Excel

Le recul du projet terminé confirme l’intuition de départ : un fichier Excel utilisé chaque jour n’est pas un tableau mal organisé. Il contient des règles métier, des habitudes, des arbitrages, des dépendances — une partie du modèle opérationnel de l’entreprise, écrite dans des cellules et complétée par ce qui n’est écrit nulle part.

Notre travail n’a donc pas consisté à « convertir Excel en application ». Il a consisté à ouvrir les fichiers, comprendre pourquoi ils existaient, suivre les flux réels, poser des questions, découvrir ce qui ne vivait que dans les conversations et les mémoires — puis structurer les données et les règles, préserver ce qui fonctionnait, et construire l’application autour du métier réel.

« Une entreprise qui nous dit “nous avons beaucoup d’Excel” ne nous montre pas forcément un problème. Elle nous montre souvent le prototype de son futur logiciel métier. »

Vous avez un fichier qui ressemble à ce point de départ ?

Faites-le regarder gratuitement : la première lecture montre ce que votre fichier pilote réellement — et s’il mérite d’aller plus loin.