Ébaucher un modèle de coûts avec un LLM, et où il se trompe

Demandez à un grand modèle de langage d’ébaucher un modèle de coûts TDABC et il en produira un volontiers : pools de coûts, inducteurs candidats, un taux de coût de capacité, et même une équation de temps d’apparence plausible. Le résultat se lit comme le travail d’un analyste compétent. L’ennui n’est pas qu’il soit faux de façon évidente : un modèle portant un chiffre manifestement faux se fait attraper vite. L’ennui est qu’il est faux comme l’est un jeune diplômé brillant sans expérience du terrain : fluide, bien structuré, et bâti sans bruit sur des hypothèses que personne dans votre entreprise n’a jamais confirmées.

Ce qu’il fait réellement bien

À partir d’une description d’entreprise, un modèle de langage produira une liste raisonnable de pools de coûts candidats et une première ébauche d’inducteurs rarement embarrassante. Il connaît le vocabulaire du calcul de coûts, il a lu beaucoup de littérature comptable, et il transforme vite une description grossière en point de départ structuré. Pour une équipe devant un tableur vide, cette première version peut épargner un après-midi entier. Il est également bon pour réexpliquer une méthode à un non-spécialiste, et pour produire la documentation que personne ne veut écrire à la main.

Là où l’entraînement s’arrête

Un modèle de coûts n’est juste que si ses chiffres décrivent votre exploitation, et aucun de ces chiffres ne figurait dans un jeu d’entraînement. Votre capacité pratique, les minutes dont une équipe dispose réellement une fois retirés les congés, la formation et les temps morts, n’existe que dans vos plannings et votre ERP. Vos volumes d’inducteurs, le nombre de changements de série, de lignes de commande ou de demandes de support que votre activité a produits le trimestre dernier, n’existent que dans vos systèmes. Un modèle à qui l’on demande d’estimer l’un de ces chiffres produira une valeur qui sonne précise et qui est en fait une supposition déguisée en fait. Il n’a aucun moyen de signaler la différence, parce que les modèles de langage sont construits pour paraître assurés, pas pour signaler un doute sur un fait qu’ils ne peuvent pas vérifier.

Le piège de la répartition des frais indirects, en particulier

Demandez à un modèle de suggérer un inducteur pour les frais informatiques et il proposera souvent l’effectif, parce que l’effectif est l’inducteur le plus fréquemment cité dans les manuels et les études de cas sur lesquels il a été entraîné. L’effectif est commode et presque jamais causal : deux services avec le même nombre de personnes peuvent consommer des quantités d’assistance informatique très différentes selon le nombre de systèmes qu’ils touchent et la complexité de leur travail. Un modèle a lu des milliers d’exemples où l’effectif servait d’inducteur et très peu où quelqu’un expliquait pourquoi c’était le mauvais choix pour cette entreprise précise. Il reproduit la réponse la plus répandue, pas la réponse juste pour vous.

Un partage du travail qui fonctionne

Le partage utile est celui entre structure et fait. Laissez le modèle ébaucher la liste des pools de coûts, proposer des inducteurs candidats auxquels réagir, et rédiger la première explication de la méthode pour ceux qui n’étaient pas dans la salle. Ne le laissez pas inventer un chiffre de capacité, un volume d’inducteur ou une répartition en pourcentage entre activités : ceux-là viennent uniquement de votre ERP, de vos feuilles de temps, de vos plannings ou d’une véritable étude de temps. Un modèle peut accélérer les parties du travail qui consistent à organiser des faits connus. Il ne peut pas fabriquer les faits eux-mêmes, aussi assurée que soit la phrase qui les contient.

Un modèle de langage écrit une phrase très convaincante sur un chiffre qu’il n’a jamais vu. C’est exactement le mode de défaillance qu’un modèle de coûts ne peut pas se permettre.

Ce qu’il faut vérifier avant de croire un modèle ébauché par l’IA

Avant qu’une répartition ébauchée par l’IA n’approche une décision de prix ou de conseil d’administration, retracez chaque chiffre jusqu’à sa source. Si un volume d’inducteur ne peut être rattaché à un rapport ou à un système précis, c’est une hypothèse et elle doit être étiquetée comme telle, pas publiée comme un fait. Demandez-vous si doubler l’inducteur doublerait plausiblement le coût : le test de causalité s’applique toujours, que l’inducteur ait été proposé par une personne ou par un modèle. Et demandez-vous si quelqu’un dans l’entreprise qui fait réellement le travail défendrait ce chiffre dans une salle. Si la réponse à l’une de ces questions est non, l’ébauche a besoin d’un humain avec les vraies données avant de devenir une décision.

À lire également : construire un modèle TDABC avec l’IA et les erreurs de répartition des coûts indirects.