Un achat ne prend pas du retard parce qu’il manque de budget. Il prend du retard parce que personne ne compare exactement la même chose. C’est le défaut que les tableaux de bord cachent souvent : le fournisseur A cote à l’unité, le B au carton et le C avec un minimum de commande ; l’un inclut le transport, l’autre le facture à part ; l’un promet dix jours ouvrés, l’autre deux semaines calendaires. À l’écran, tout semble propre. En réalité, l’équipe achats traduit des documents au lieu de décider.
La bonne question n’est pas de savoir si l’IA peut choisir à votre place, mais si elle peut mettre toutes les offres dans la même langue avant la signature.
Ma thèse est simple : dans les achats de PME traditionnelles, l’IA vaut davantage comme normalisateur que comme décideur. Si elle aligne d’abord les unités, les délais et les conditions, la comparaison s’améliore ; si elle recommande trop tôt, elle ne fait que polir le bruit.
Le vrai goulot n’est pas le prix
Dans beaucoup d’entreprises, achats, opérations et entrepôt ne regardent pas la même chose. Les achats veulent clôturer vite. Les opérations veulent éviter l’arrêt. L’entrepôt veut éviter l’encombrement. La finance veut que la facture corresponde à ce qui a été convenu. Quand chaque service défend son propre indicateur, le résultat est un travail de rapprochement manuel.
Un signe clair apparaît dans les comportements : des emails du type « transport inclus ? », des tableurs avec des colonnes ajoutées à la dernière minute, et des décisions repoussées parce qu’il faut « confirmer le vrai délai de livraison ». Ce n’est pas d’abord un problème technique. C’est un problème de langage et d’incitations.
L’IA peut lire les offres et extraire des champs comparables : article, unité, quantité, prix net, transport, taxes, délai, validité, conditions de paiement et pénalités. Mais cette extraction n’est pas encore une décision. C’est un prétraitement opérationnel.
À quoi ressemble le processus, étape par étape
Un flux raisonnable pour une PME serait le suivant :
- Entrée : offres reçues par email, PDF ou Excel, plus la demande d’achat interne.
- Tâche IA : lire chaque document et proposer un tableau commun avec des champs normalisés.
- Règle métier : convertir le tout dans une unité de référence commune et signaler les hypothèses. Par exemple, si un fournisseur vend par carton, la comparaison doit montrer le coût à l’unité, pas seulement le coût par carton.
- Validation humaine : les achats vérifient les écarts importants et les opérations confirment si le délai convient au besoin réel.
- Résultat mesurable : moins de temps de comparaison, moins d’erreurs de saisie et plus de traçabilité sur le choix final.
L’important est de séparer trois choses : l’interprétation par l’IA, le calcul déterministe et l’intégration au système. L’IA interprète le texte. Le tableur calcule. L’ERP enregistre la décision.
L’erreur inconfortable : laisser l’IA décider seule
Il faut être direct : si une entreprise utilise l’IA pour valider automatiquement les achats, elle déplace le risque sans régler la cause du problème. Elle peut gagner du temps aujourd’hui et faire un mauvais achat demain.
Le risque le plus courant n’est pas une hallucination spectaculaire de l’IA, mais une petite erreur de normalisation : confondre jours ouvrés et jours calendaires, oublier un minimum de commande ou ignorer une durée de validité courte. En achats, une petite erreur peut devenir une rupture de stock, un excédent d’inventaire ou un conflit avec la production.
NIST recommande de traiter l’IA comme un risque à gérer tout au long du cycle de vie, avec des fonctions de gouvernance, de cartographie, de mesure et de gestion. Le cadre insiste aussi sur une gestion continue et contextuelle, pas sur une simple liste de vérification mécanique. (nist.gov)
Un scénario bref : trois devis, une comparaison utile
Imaginez un distributeur qui achète des emballages pour plusieurs lignes de produits. Un devis semble bon marché, mais il est exprimé par grand carton ; un autre a un meilleur délai, mais le transport est séparé ; le troisième paraît plus cher jusqu’à ce que tout soit converti au coût unitaire et au coût livré.
Avant, l’équipe passait une demi-journée à reconstruire la comparaison. Après l’introduction d’un assistant qui extrait les champs et signale les écarts, le temps baisse parce qu’on ne part plus de documents dispersés, mais d’un tableau vérifié. La décision reste humaine, mais la discussion passe de « que disait chaque PDF ? » à « quelle option convient le mieux à l’exploitation ? ». Ce petit déplacement change beaucoup de choses.
Ce qu’il faut vérifier avant d’élargir le pilote
Il n’est pas nécessaire de lancer un grand programme d’IA. Il faut un test réversible. Pendant deux ou trois semaines, mesurez trois signaux : le temps de comparaison par dossier, le nombre de questions récurrentes et la part des offres nécessitant une correction manuelle sur l’unité ou le délai.
Si le pilote fonctionne, élargissez-le. Sinon, vous aurez peu perdu et vous saurez où se situe le bruit : dans l’entrée, dans les règles ou dans la validation.
La meilleure décision n’est pas « automatiser les achats », mais déterminer précisément quelle partie du travail doit être faite par l’IA et quelle partie doit rester humaine.
Trois actions utiles cette semaine :
- Quelles données comparez-vous encore à la main dans chaque devis, et lesquelles pourraient être normalisées ?
- Où apparaissent le plus souvent les erreurs : unité, délai ou conditions de paiement ?
- Quel petit pilote pourriez-vous tester sans toucher à la validation finale ?
Si vous le souhaitez, Codefuente peut vous aider à concevoir ce flux pour que l’IA réduise la friction sans enlever le contrôle.