L’information existe, elle est juste éparpillée
Aucune donnée ne manque vraiment. Le bon de commande est dans les documents envoyés. L’accusé de réception est dans la boîte de la personne qui a commandé. Le bon de livraison est sur un bureau, ou dans une camionnette. La facture est chez le comptable.
Chacun de ces documents est correct. Ce qui n’existe pas, c’est leur rapprochement, et donc la seule chose dont on a besoin : l’état.
D’où les symptômes familiers. On relance un fournisseur qui a déjà expédié. On ne relance pas celui qui a oublié. On paie une facture pour une livraison partielle. On découvre qu’un article a augmenté de douze pour cent depuis le devis, trois factures plus tard. Et quand une pièce manque sur un chantier, la première demi-heure se passe à chercher qui savait quoi.
Ce qu’on automatise
La centralisation. Une adresse dédiée aux achats ; tout y converge, quelle que soit la personne qui a commandé.
L’identification des documents. Accusé, avis d’expédition, bon de livraison, facture, avoir — et rattachement à la commande.
L’état des commandes. Par ligne : commandé, confirmé, expédié, reçu, facturé, soldé. Avec le reliquat.
La détection de retard. Alerte avant l’échéance quand c’est utile, et relance préparée après.
Le rapprochement à trois documents et le chiffrage des écarts de prix, de quantité et d’article.
La mémoire fournisseur. Délai réel constaté par fournisseur et par famille d’articles, taux de conformité des livraisons, fréquence des écarts de facturation. Ces chiffres n’existent nulle part aujourd’hui et changent les négociations.
Les alertes de stock quand vous tenez un stock, avec proposition de commande préparée.
Comment ça marche techniquement — pour qui veut le détail
L’entrée. Boîte IMAP dédiée avec IDLE pour réagir sans interrogation en boucle. Les pièces jointes sont extraites, les PDF texte lus directement — pdftotext de poppler avec préservation de la mise en page —, les PDF scannés passés à Tesseract après redressement. Le corps du message compte aussi : beaucoup de fournisseurs annoncent l’expédition dans le texte sans joindre de document.
La classification du document. Motifs d’abord, et ils suffisent souvent : les mots-clés de l’objet et de l’en-tête (accusé de réception, bon de livraison, avis d'expédition, facture n°), la présence d’un numéro de TVA intracommunautaire, la structure tabulaire. Un modèle n’intervient que sur les documents non classés, et renvoie une structure validée par schéma.
L’extraction des lignes. C’est la partie difficile, et elle mérite d’être décrite honnêtement. Un tableau dans un PDF n’est pas un tableau : c’est un ensemble de fragments de texte avec des coordonnées. On reconstruit les lignes par regroupement sur l’axe vertical et les colonnes par analyse des positions horizontales — pdfplumber en Python fait ce travail correctement. Pour un fournisseur régulier, on stocke un gabarit : les colonnes toujours au même endroit, une fois calibré, donnent une extraction fiable et gratuite. Les fournisseurs occasionnels passent par l’extraction générique, moins sûre, avec contrôle humain sur les écarts.
Les contrôles arithmétiques. Quantité × prix unitaire = montant de ligne ; somme des lignes = total HT ; TVA cohérente avec les taux. Une extraction qui échoue à ces contrôles est rejetée avant tout rapprochement. Ce filtre élimine la plupart des erreurs de lecture sans aucune intelligence particulière.
Le rapprochement commande-réception-facture. Rapprochement par référence de commande quand elle figure sur le document, ce qui est le cas le plus simple. Sinon, faisceau : fournisseur identifié par son SIREN ou son domaine de messagerie, fenêtre de dates, correspondance des lignes par référence article ou par similarité de désignation (trigrammes après normalisation), montants. Chaque rapprochement de ligne porte un score ; en dessous du seuil, contrôle humain.
Les tolérances. Un écart de prix inférieur à un seuil paramétrable et un écart de quantité nul peuvent passer sans intervention — mais l’écart est toujours enregistré, même quand il est toléré. C’est le cumul de ces petits écarts tolérés qui constitue l’information intéressante en fin d’année, et l’effacer au motif qu’il est individuellement négligeable fait perdre exactement ce qu’on cherchait.
Le modèle de données. commande → ligne_commande → réception_ligne (plusieurs par ligne de commande, cumulables) → ligne_facture. Le reliquat est calculé, jamais stocké : quantité commandée moins somme des quantités reçues. Stocker un reliquat, c’est garantir qu’il finira désynchronisé.
Les échéances. Table d’échéances consommée par un travailleur régulier, avec FOR UPDATE SKIP LOCKED — même mécanique que pour toute relance durable. La date attendue vient de l’accusé quand il existe, du délai contractuel sinon, et à défaut de la médiane des délais réellement constatés pour ce fournisseur sur cette famille d’articles. Cette médiane, calculée sur votre historique, est souvent plus juste que le délai annoncé.
Les indicateurs fournisseurs. Vue matérialisée : délai médian et son écart, taux de livraison complète au premier envoi, fréquence et ampleur des écarts de prix, taux de litige. Rafraîchie chaque nuit. Ce sont des chiffres qui n’existent dans aucun outil courant de PME et qui changent le rapport de force en renégociation annuelle.
L’échange structuré. Quand un fournisseur important propose l’EDI (EDIFACT ORDERS, DESADV, INVOIC) ou une API, on le branche : l’extraction disparaît et la fiabilité devient totale sur ce flux. Cela vaut le déplacement pour les deux ou trois fournisseurs qui représentent l’essentiel du volume, et cela n’a aucun sens pour les autres.