Les concepts clés
Lexique
J'attire votre attention sur les principaux concepts dont j'ai eu besoin pour construire le système financier de mon entreprise.
Ils sont rangés dans l'ordre où on les rencontre quand on construit.
Le système sait de quoi il parle
Couche sémantique
L'endroit où une entreprise décide une fois pour toutes ce que veut dire chiffre d'affaires ou marge, et où tous les écrans vont chercher cette définition.
Aussi : semantic layer, référentiel d'indicateurs, couche de définitions
Une couche sémantique, c’est l’endroit unique où sont écrites les définitions de vos indicateurs.
Comment calculez-vous votre marge ? Probablement pas comme votre concurrent, parce que vous n’y mettez pas la même chose.
Prenez deux ateliers de menuiserie. Même métier, même taille, et le même chantier à 100 000 euros. Le premier retire de la vente ce qu’il a acheté, 42 000 euros de bois et de quincaillerie, et annonce 58 % de marge. Le second retire la même matière, puis les heures d’atelier et la pose, 31 000 euros de plus, et annonce 27 %. Même chantier, même argent en banque à la fin de l’année. Deux chiffres du simple au double, et aucun des deux n’est faux.
Les textes ne vous départageront pas. Le plan comptable dit ce qu’on met dans un coût de production pour valoriser un stock, main d’œuvre directe comprise. Il ne dit rien de ce que vous appelez marge le lundi matin en réunion.
Et ça se paie. Le jour où un client demande 15 % de remise, le premier la donne en pensant qu’il lui reste 43 points. Le second sait qu’il lui en reste 12. Sur un chantier, ça passe. Sur une année de chantiers, c’est le résultat.
L’enjeu est donc de définir une seule fois ce qu’est la marge, et qu’à chaque fois qu’on en parle dans ce système, on sache de quoi on parle. On n’y déroge plus.
À ne pas confondre avec l’ontologie, qui dit ce que sont les objets quand la couche sémantique dit comment on les mesure. Ni avec un tableau de bord, qui affiche un chiffre sans jamais décider de quoi ce chiffre est le nom.
SourcesBrevet US 5 555 403, Relational Database Access System Using Semantically Dynamic Objects, déposé le 27 novembre 1991, délivré le 10 septembre 1996, inventeurs Jean-Michel Cambot et Bernard Liautaud · ISO/IEC 11179-1:2023, Information technology, Metadata registries (MDR), Part 1: Framework, 4e édition, janvier 2023 · Règlement ANC n° 2014-03 relatif au plan comptable général, article 213-32, coût de production des stocks
Ontologie
La carte qui dit à une machine ce qu'est un client, une commande ou une facture chez vous, et comment ces choses se tiennent entre elles.
Aussi : graphe de connaissances, knowledge graph, modèle métier
Une ontologie, c’est la liste écrite de ce qui existe dans votre entreprise et de ce qui s’y rattache. Un client, ses commandes, ses factures, ses paiements. Pas les tables de vos logiciels, les choses elles-mêmes, avec les liens entre elles et les règles qu’elles doivent respecter. Le mot vient de la philosophie, il est passé à l’informatique au début des années 1990, et la définition qu’il a reçue à ce moment-là n’a pas bougé depuis.
Ce que ça change quand on construit son pilotage tient dans une seule question. Combien coûte la prochaine question que vous n’aviez pas prévue. Sans ontologie, votre système répond très bien à ce pour quoi il a été paramétré et à rien d’autre. Dès que vous demandez la marge par client sur douze mois, quelqu’un ressort des exports, les retraite, les recolle, et vous avez la réponse trois jours plus tard. Les données étaient là depuis deux ans. Ce qui manquait, c’est que personne n’avait jamais écrit que le Martin SAS du logiciel de vente, le Martin de la facturation et les Ets Martin de l’encaissement sont la même entreprise.
Une fois que c’est écrit, la machine tient le lien tous les jours, sur ce qui arrive comme sur ce qui est déjà là, et la question suivante coûte cinq minutes au lieu de trois jours. C’est ce qui décide de la liste des chiffres que vous regardez vraiment. On finit toujours par cesser de poser les questions trop chères, et ce sont presque toujours celles qui portent la marge.
Ce n’est pas gratuit pour autant. Il faut que quelqu’un décide, une bonne fois, que ces trois lignes sont le même client, et cette décision-là n’est pas technique. La machine ne la prendra pas à votre place.
À ne pas confondre avec le schéma de votre base de données. Le schéma dit comment les données sont rangées. L’ontologie dit ce qu’elles veulent dire.
SourcesThomas Gruber, A Translation Approach to Portable Ontology Specifications, Knowledge Acquisition, 5(2), 199-220, 1993 · W3C, OWL 2 Web Ontology Language Document Overview (Second Edition), W3C Recommendation, 11 décembre 2012
Réconciliation
Comparer deux systèmes qui prétendent détenir le même chiffre, et expliquer l'écart ligne à ligne au lieu de choisir celui qui arrange.
Aussi : rapprochement, reconciliation, lettrage
Réconcilier, c’est prendre deux systèmes qui prétendent détenir la même vérité et vérifier qu’ils disent la même chose. La comptabilité et l’analytique. Le carnet de commandes et la facturation. Ce qui a été livré et ce qui a été facturé. Ce n’est pas une technique, c’est un contrôle, et ça restera vrai quels que soient vos logiciels.
Le droit fiscal en fait d’ailleurs une obligation. Une directive européenne de 2010 en a posé le principe, et la loi française retient depuis la même formule : à défaut d’un procédé technique reconnu, l’entreprise doit mettre en place des contrôles documentés et permanents qui établissent une piste d’audit fiable entre la facture émise ou reçue et la livraison de biens ou la prestation de services qui en est le fondement. Autrement dit, savoir rapprocher ce que vous facturez de ce que vous livrez n’est pas une question de rigueur interne, c’est la loi. Et des trois mots, le plus exigeant est permanents.
Ce que ça change quand on construit son pilotage est plus dur à entendre. La première fois qu’on rapproche la comptabilité et l’analytique d’une PME, l’écart fait plusieurs points, et il vient de quelques règles d’affectation que personne n’avait jamais écrites. Une charge qui tombe sur le mauvais chantier, un avoir qui n’est jamais remonté, des heures passées sur une affaire et saisies sur une autre. Tant que cet écart n’est pas expliqué ligne à ligne, aucune décision ne devrait se prendre sur le chiffre analytique. C’est pourtant celui qui s’affiche sur les tableaux de bord, et celui sur lequel on arbitre un prix.
Une réconciliation n’est donc pas un chantier qu’on mène une fois. Elle est permanente ou elle n’existe pas, parce que l’écart réapparaît dès qu’une règle change sans que personne l’écrive.
À ne pas confondre avec le rapprochement bancaire, qui n’en est que le cas le plus connu, celui où les deux systèmes comparés sont votre relevé et vos écritures.
SourcesDirective 2010/45/UE du Conseil du 13 juillet 2010, article 233, Journal officiel de l'Union européenne L 189/1 du 22 juillet 2010 · Ordonnance n° 2025-1247 du 17 décembre 2025, nouvelle rédaction du I bis de l'article L. 102 B du livre des procédures fiscales, en vigueur le 1er septembre 2026
Le système fait le travail
Agent
Un logiciel qui choisit lui-même l'étape suivante au lieu de suivre un chemin écrit d'avance, et c'est ce choix qui change tout le reste.
Aussi : agent autonome, agent logiciel, autonomous agent
Un agent est un logiciel qui décide de ce qu’il fait ensuite.
La définition de référence date de 1995 et elle tient en quatre propriétés :
- il agit sans qu’on intervienne à chaque étape, et garde un certain contrôle sur ses actions,
- il perçoit ce qui se passe autour de lui,
- il y réagit dans un délai utile,
- et il prend l’initiative au lieu d’attendre qu’on l’appelle.
Le règlement européen de 2024 sur l’intelligence artificielle dit la même chose autrement. Il parle de systèmes conçus pour fonctionner à différents niveaux d’autonomie, et qui déduisent eux-mêmes la manière de produire leur résultat.
À ne pas confondre avec une automatisation. Le point commun, c’est que la machine fait à votre place. La différence, c’est que l’agent choisit l’étape suivante, et qu’il faut donc se demander ce qui se passe quand il la choisit mal. Une automatisation, elle, suit un chemin préétabli. On la teste une fois, et le jour où elle casse, elle casse sec.
C’est aussi ce qui décide de son prix réel. Un agent qu’il faut vérifier à chaque passage coûte plus cher que pas d’agent du tout, parce que vérifier prend plus de temps que faire.
Autrement dit : l’automatisation ne décide pas de la tâche suivante. L’agent, si.
Le mot sert dans L'IA dans les finances de mon entreprise : voilà où je veux en être dans deux mois (et j'y suis presque).
SourcesMichael Wooldridge et Nicholas Jennings, Intelligent Agents: Theory and Practice, The Knowledge Engineering Review, 10(2), 115-152, 1995 · Règlement (UE) 2024/1689 du 13 juin 2024 établissant des règles harmonisées concernant l'intelligence artificielle, article 3, paragraphe 1
Aiguillage
Classer ce qui arrive avant de le traiter, pour envoyer chaque cas au traitement fait pour lui plutôt qu'un traitement moyen à tous.
Aussi : routing, routage, classer puis diriger
L’aiguillage (routing) consiste à regarder ce qui arrive, à le classer, puis à l’envoyer vers le traitement fait pour lui. Le cas courant part vers un traitement rapide et bon marché. Le cas rare part vers un traitement plus lourd, ou vers une personne.
Ce qui compte n’est pas la classification, c’est ce qu’elle permet derrière. Chaque traitement peut être spécialisé. Sans aiguillage, on écrit une seule règle qui doit servir tous les cas, et l’améliorer pour les uns la dégrade pour les autres.
C’est déjà le travail d’un service comptable. Une facture arrive, quelqu’un décide de quel compte et de quel axe elle relève. Ce tri fait la moitié du métier, il repose sur des gens qui connaissent la maison, et il n’est écrit nulle part.
C’est aussi là que se perd la lisibilité de la marge. Une charge mal aiguillée n’est pas perdue, elle est comptée ailleurs. Le résultat global reste juste, et c’est ce qui rend l’erreur invisible. Mais l’affaire qui porte cette charge a l’air rentable, une autre a l’air mauvaise, et vous arbitrez sur du faux. Vous arrêtez la mauvaise activité.
Le coût est l’autre moitié du sujet. Les travaux sur les cascades ont montré qu’orienter les demandes selon leur difficulté, au lieu d’envoyer tout au traitement le plus puissant, tient la même qualité pour une fraction du prix. Ce n’est pas la puissance qui décide de ce que coûte un système, c’est le tri à l’entrée.
À ne pas confondre avec une règle de validation. Une règle dit oui ou non. Un aiguillage ne juge pas, il oriente. Et le cas qu’il ne sait pas classer doit partir chez quelqu’un, jamais dans une catégorie divers, qui est l’endroit exact où votre marge va mourir.
SourcesErik S. et Barry Zhang, Building effective agents, Anthropic Engineering, 19 décembre 2024, section Workflow: Routing · Lingjiao Chen, Matei Zaharia et James Zou, FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance, arXiv:2305.05176, 9 mai 2023
Chaînage de prompts
Découper un traitement en étapes courtes où chaque étape reprend la sortie de la précédente, et poser un contrôle entre deux.
Aussi : prompt chaining, chaîne de prompts, chaînage
Le chaînage de prompts (prompt chaining) consiste à découper une tâche en étapes courtes et à faire passer la sortie de chacune en entrée de la suivante. Au lieu de demander une grosse chose une fois, on demande quatre petites choses quatre fois.
Entre deux étapes, on pose un contrôle. Il vérifie que le résultat intermédiaire tient, et il arrête tout s’il ne tient pas. C’est le point du schéma, pas le découpage. Découper améliore la qualité parce que chaque demande devient plus facile, mais ce qu’on gagne vraiment, c’est de voir ce qui s’est passé à l’étape trois. On échange du temps contre de la justesse.
Une clôture, une refacturation interne, un calcul de marge sont déjà des chaînes. Personne ne calcule une marge en un geste. Ce qui manque presque toujours, ce ne sont pas les étapes, ce sont les contrôles entre les étapes.
Prenez une refacturation interne en quatre temps. On collecte les temps passés, on les affecte à une entité, on applique la clé de répartition, on émet la facture. Si la clé s’applique sur un périmètre incomplet parce que deux personnes n’ont pas saisi, rien ne le signale. Le calcul tombe juste, il est simplement faux. On le découvre au trimestre, et on le corrige en avoir, avec de la TVA à reprendre et un compte interco qui ne se ferme plus des deux côtés.
Le même travail avec un contrôle après l’étape deux, du type le total des heures affectées égale-t-il le total des heures saisies, s’arrête avant la clé. Une erreur attrapée à l’étape deux coûte dix minutes, la même attrapée après l’émission coûte un trimestre.
À ne pas confondre avec un enchaînement de tâches automatisées. Un enchaînement classique passe à la suite quoi qu’il arrive. Une chaîne bien faite a des portes, et une porte sert d’abord à ne pas passer.
SourcesErik S. et Barry Zhang, Building effective agents, Anthropic Engineering, 19 décembre 2024, section Workflow: Prompt chaining · Tongshuang Wu, Michael Terry et Carrie J. Cai, AI Chains: Transparent and Controllable Human-AI Interaction by Chaining Large Language Model Prompts, arXiv:2110.01691, 4 octobre 2021 · Prompting best practices, documentation de la plateforme Claude, section Chain complex prompts, consultée le 14 août 2026
Méthode
Une manière de faire spécifiée qu'on peut rejouer à l'identique, et qui ne vaut pas la même chose selon qu'elle est écrite quelque part ou seulement dans une tête.
Aussi : skill, mode opératoire, routine organisationnelle, standard operating procedure
Une méthode, c’est une manière de faire spécifiée, qu’on peut rejouer et qui donne le même résultat. Les normes d’ingénierie la définissent ainsi, une manière spécifiée de réaliser une activité ou un processus. Le mot anglais qui circule en ce moment est skill, et il désignera peut-être autre chose dans cinq ans. La chose, elle, ne bouge pas.
Ce qui compte n’est pas la définition, c’est l’endroit où elle vit. Une méthode peut vivre à deux endroits, dans la tête de quelqu’un qui la répète, ou écrite quelque part. Nelson et Winter l’ont posé en 1982, dans le travail qui a fondé l’économie évolutionniste : une entreprise se souvient d’abord en faisant, pas en archivant. Son savoir-faire est stocké dans ses gestes répétés. Et ils donnent la raison, qui est économique. Écrire coûtait plus cher que refaire.
C’est exactement ce qui vient de changer de prix. Tant que votre clôture, votre refacturation ou votre calcul de marge vivent dans la tête de la personne qui les fait, ce ne sont pas des actifs de l’entreprise, ce sont des dépendances. Elles ne se corrigent qu’une personne à la fois, elles ne se transmettent qu’en montrant, et elles coûtent trois semaines de retard le jour où cette personne est en congés, en arrêt ou partie. Écrites, elles se rejouent par n’importe qui, elles se corrigent une fois pour toutes, et les relancer ne coûte presque rien.
La question à se poser n’est donc pas combien de méthodes vous avez. C’est combien d’entre elles survivraient à un départ.
À ne pas confondre avec la documentation. Un document décrit ce qu’on est censé faire. Une méthode est ce qu’on exécute. On peut avoir cent pages de procédures dans un classeur et pas une seule méthode qui tourne.
SourcesRichard R. Nelson et Sidney G. Winter, An Evolutionary Theory of Economic Change, Harvard University Press, 1982, chapitre 5, section 1, Routine as Organizational Memory · ISO/IEC/IEEE 24765:2017, Systems and software engineering, Vocabulary, définition de procedure, manière spécifiée de réaliser une activité ou un processus
Orchestrateur et exécutants
Un programme central découpe une question en sous-tâches qu'il ne connaissait pas d'avance, les distribue, puis recompose la réponse.
Aussi : orchestrator-workers, agent chef d'orchestre, sous-agents, délégation dynamique
Dans ce schéma (orchestrator-workers), un programme central reçoit la question, décide lui-même comment la découper, distribue les morceaux à des exécutants qui travaillent chacun de leur côté, et recompose leurs réponses.
La différence avec la parallélisation tient en deux mots : à l’avance. En parallélisation, on connaît les morceaux avant de commencer. Ici, non. C’est la question posée qui détermine combien de pistes il faut suivre et lesquelles.
C’est la forme exacte d’une analyse d’écart, et c’est pourquoi aucun tableau de bord ne l’a jamais remplacée. Pourquoi ma marge a baissé de trois points ce mois-ci n’a pas de nombre d’étapes connu. C’est peut-être un prix d’achat, peut-être une affaire, peut-être des heures mal saisies, peut-être les trois ensemble. On ne le sait pas avant d’avoir cherché. Aujourd’hui cette recherche prend deux jours à quelqu’un, et elle arrive après que la décision a été prise sans elle.
Le prix est connu et il est élevé. Ces montages consomment de l’ordre de quinze fois ce que coûte une simple conversation avec une machine. On ne les met donc que sur des questions dont la réponse vaut plus cher que sa fabrication, ce qui, pour trois points de marge, se tranche vite, et ce qui exclut d’emblée les tâches répétitives à faible enjeu.
Il exige aussi une chose que personne n’anticipe. L’orchestrateur doit dire précisément à chaque exécutant ce qu’il attend de lui, avec un objectif, un format de sortie et une frontière nette. Une consigne vague et deux exécutants font le même travail pendant qu’une partie de la question n’est traitée par personne.
À ne pas confondre avec déléguer. Un orchestrateur ne se décharge pas, il découpe, il distribue et il reste tenu de recomposer. Le travail difficile n’est pas d’exécuter les morceaux, c’est de décider lesquels.
SourcesErik S. et Barry Zhang, Building effective agents, Anthropic Engineering, 19 décembre 2024, section Workflow: Orchestrator-workers · How we built our multi-agent research system, Anthropic Engineering, 13 juin 2025, sections Benefits of a multi-agent system et Architecture overview
Parallélisation
Traiter un même travail en plusieurs fois simultanément, soit en le découpant en morceaux indépendants, soit en le refaisant pour comparer.
Aussi : parallelization, découpe en sous-tâches, vote, contrôle croisé
La parallélisation (parallelization) prend deux formes, et elles ne servent pas du tout à la même chose.
La première découpe un travail en morceaux indépendants traités en même temps, puis rassemble. Quatre filiales analysées ensemble plutôt que l’une après l’autre. On gagne du temps.
La seconde refait le même travail plusieurs fois et compare les résultats. On ne gagne pas de temps, on gagne de la confiance. C’est un résultat établi dès 2022 sur les tâches de calcul : produire plusieurs raisonnements sur un même problème et retenir la réponse la plus fréquente améliore nettement la justesse par rapport à un seul passage.
La seconde forme est celle qui compte pour vous, parce qu’elle porte déjà un nom en finance : le contrôle croisé. On ne valide pas un paiement de quarante mille euros sur une seule lecture, et on ne le fait pas par méfiance envers la personne qui a lu.
Ce que la parallélisation ajoute, c’est que le désaccord devient une information exploitable. Trois passages qui donnent le même chiffre, on signe. Trois passages qui donnent trois chiffres, on ne signe pas, et on sait où regarder. Le désaccord est le meilleur détecteur d’ambiguïté qui existe. Quand deux lectures d’une même règle divergent, ce n’est pas la lecture qui est mauvaise, c’est votre règle qui n’est pas écrite.
Elle coûte, et c’est la limite à tenir. Trois passages coûtent trois fois. On les met là où l’erreur coûte plus cher que le triple, un paiement, une déclaration fiscale, un engagement signé, et nulle part ailleurs. Mis partout, ce contrôle devient une taxe permanente sur des opérations qui ne risquent rien.
À ne pas confondre avec la répartition d’un travail entre plusieurs personnes. Ici les morceaux sont décidés avant de commencer. Quand c’est la machine qui décide en cours de route de quoi découper, ce n’est plus de la parallélisation.
SourcesErik S. et Barry Zhang, Building effective agents, Anthropic Engineering, 19 décembre 2024, section Workflow: Parallelization · Xuezhi Wang et al., Self-Consistency Improves Chain of Thought Reasoning in Language Models, arXiv:2203.11171, 21 mars 2022, publié à ICLR 2023
Le système rend des comptes
Degré de confiance et fourchette
Annoncer un chiffre avec la fourchette dans laquelle il se tient et ce qu'on parie dessus, pour qu'il se décide au lieu de se rediscuter.
Aussi : fourchette, incertitude, marge d'incertitude
Annoncer un chiffre avec son degré de confiance, c’est en donner trois au lieu d’un. Le montant, la fourchette dans laquelle il se tient, et ce que vous pariez sur cette fourchette. Le résultat à date est de 480 000 euros, à 40 000 près, et je le tiens à 80 %. Les vingt pour cent qui manquent ne sont pas de la modestie. Ils désignent ce que vous savez qu’il vous manque et que vous n’avez pas encore chiffré.
La mesure a formalisé cette idée, et sa règle est plus exigeante qu’il n’y paraît. Le guide international sur l’expression de l’incertitude de mesure pose qu’un résultat n’est complet que lorsqu’il est accompagné d’une expression de son incertitude. Un chiffre nu n’est donc pas un chiffre prudent, c’est un chiffre incomplet.
Ce que ça change se joue au moment où le chiffre arrive en réunion. Un résultat à date annoncé nu se rediscute, parce que tout le monde sait qu’il manque des choses et que personne ne sait lesquelles. La réunion parle alors de la fiabilité du chiffre au lieu de parler de la décision, et l’arbitrage repart au mois suivant.
Le même résultat annoncé à 40 000 près, avec la liste de ce qui manque, se tranche le jour même, parce que la question devient utile : est-ce que ma décision change si l’écart tombe du mauvais côté ? Souvent non, et vous venez de gagner un mois.
Le mot sert dans L'IA dans les finances de mon entreprise : voilà où je veux en être dans deux mois (et j'y suis presque).
SourcesJCGM 100:2008, Évaluation des données de mesure, Guide pour l'expression de l'incertitude de mesure, Bureau international des poids et mesures, édition française, 2008 · Barry N. Taylor et Chris E. Kuyatt, Guidelines for Evaluating and Expressing the Uncertainty of NIST Measurement Results, NIST Technical Note 1297, édition 1994
Évaluateur et optimiseur
Un premier passage produit, un second le critique, et on recommence jusqu'à ce que le résultat passe le critère fixé d'avance.
Aussi : evaluator-optimizer, boucle de critique, générateur et critique, raffinement itératif
Dans ce schéma (evaluator-optimizer), un premier passage produit un résultat, un second le critique au regard d’un critère, et le premier recommence en tenant compte de la critique. On boucle jusqu’à ce que ça passe.
Le gain a été mesuré dès 2023. Une production relue et corrigée à partir de son propre retour bat une production faite en un seul coup. Mais la condition est ferme : il faut un critère d’évaluation clair. Sans lui, la boucle tourne, consomme, et n’améliore rien de vérifiable.
Cette condition est une bonne nouvelle pour la finance, parce que c’est un des rares métiers où les critères sont déjà écrits, chiffrés et opposables. Une balance équilibre ou non. Un rapprochement bancaire tombe à zéro ou non. Un compte de liaison se ferme des deux côtés ou non. Vous n’avez pas à inventer le critère, il vous précède de deux siècles.
C’est ce qui explique qu’une clôture s’outille bien mieux qu’une note de synthèse. On sait dire à quel moment c’est fini.
Et là où le critère n’existe pas, ce schéma vous le fait remarquer tout de suite, ce qui vaut le déplacement. Si vous ne savez pas dire à quelle condition un travail est bon, personne ne peut le faire à votre place, ni une machine ni la personne que vous venez de recruter.
À ne pas confondre avec un contrôle final. Un contrôle final constate et rend le dossier. Ici la critique repart en production, et c’est la boucle qui produit le gain. Le risque est de l’autre côté : une boucle sans condition d’arrêt tourne indéfiniment vers un critère qu’elle n’atteindra jamais, et vous payez chaque tour. On fixe donc toujours deux choses, ce qui vaut réussite, et le nombre de tours au-delà duquel on rend la main.
SourcesErik S. et Barry Zhang, Building effective agents, Anthropic Engineering, 19 décembre 2024, section Workflow: Evaluator-optimizer · Aman Madaan et al., Self-Refine: Iterative Refinement with Self-Feedback, arXiv:2303.17651, 30 mars 2023
Humain in the loop
Le point de passage obligé où une personne engage sa responsabilité avant qu'une décision produite par une machine ne parte.
Aussi : humain dans la boucle, HITL, contrôle humain, supervision humaine
Un humain in the loop (humain dans la boucle), c’est la personne sans l’accord de qui rien d’important ne se fait.
La machine prépare, elle calcule, elle propose. Une personne regarde, et c’est elle qui engage. Ce n’est pas seulement une bonne pratique, c’est écrit dans le droit européen : depuis 2016, chacun peut exiger une intervention humaine face à une décision entièrement automatisée qui le concerne, et depuis 2024, un contrôle humain effectif est imposé sur les systèmes à haut risque.
Devant une banque, devant un commissaire aux comptes, devant l’administration, quelqu’un doit pouvoir dire qu’il sait pourquoi ce chiffre est vrai. Une machine ne peut pas engager sa responsabilité, et elle ne le pourra pas davantage dans cinq ans. Le travail consiste donc à choisir les endroits où l’accord humain est obligatoire, et surtout à ne pas les mettre partout.
Partout, ça ne tient pas. Une personne à qui on demande de valider trois cents lignes par semaine valide sans lire au bout d’un mois, et vous payez un contrôle qui n’existe plus.
À ne pas confondre avec un droit de regard. Voir après coup ce qu’une machine a fait n’est pas être dans la boucle. Être dans la boucle, c’est que rien ne parte tant que vous n’avez pas dit oui.
SourcesRèglement (UE) 2016/679 relatif à la protection des données, article 22, texte publié par la Commission nationale de l'informatique et des libertés · Règlement (UE) 2024/1689 du 13 juin 2024 établissant des règles harmonisées concernant l'intelligence artificielle, article 14, contrôle humain
Norme et seuil
La valeur que vous attendez sur un indicateur, et l'écart à partir duquel vous agissez. Sans le second, tout remonte, donc plus rien ne remonte.
Aussi : seuil d'alerte, valeur de référence, limite de contrôle, tolérance
Une norme, au sens où on l’entend ici, c’est la valeur que vous attendez sur un indicateur, écrite à l’avance. La marge brute de cette activité se tient à 34 %. Le seuil, c’est l’écart au-delà duquel vous agissez. Sous 31, on ouvre le sujet. Les deux ne servent à rien séparés. Une norme sans seuil ne dit pas quand réagir, un seuil sans norme ne dit pas par rapport à quoi.
Deux métiers en ont fait une discipline écrite. En audit, la norme sur le caractère significatif retient qu’une anomalie compte si l’on peut raisonnablement s’attendre à ce qu’elle influence les décisions économiques des utilisateurs des comptes, et elle précise que fixer ce montant relève du jugement professionnel, pas d’un calcul. Elle ajoute une idée qu’on oublie toujours, un second seuil placé sous le premier, parce que des écarts individuellement négligeables finissent par s’additionner. En production, les cartes de contrôle tracent des limites qui séparent la variation ordinaire, qu’on laisse vivre, d’une cause assignable, qu’on va chercher. Et le choix de ces limites décide du risque d’aller chercher une cause qui n’existe pas.
Ce que ça change quand on construit son pilotage est brutal. Sans seuil écrit, tout écart remonte, et comme tout remonte, plus rien ne remonte. Celui qui reçoit trente alertes par semaine cesse de les lire au bout d’un mois, et la semaine où un chantier dérape vraiment, l’alerte arrive au milieu des vingt-neuf autres et se traite comme elles. Vous découvrez la dérive à la facturation finale au lieu du troisième mois, quand il restait encore de quoi renégocier. Écrire le seuil coûte une réunion. Ne pas l’écrire coûte la marge d’un chantier par an, et vous ne saurez jamais lequel.
À ne pas confondre avec un objectif. Un objectif est ce que vous voulez atteindre, un seuil est ce qui déclenche quelque chose quand il est franchi. Les confondre transforme chaque objectif manqué en incident, et vous revoilà avec trente alertes. Le mot norme, enfin, ne désigne pas ici un texte officiel publié par un organisme, même si les deux sens se croisent. Celle dont on parle est la vôtre, elle tient en une ligne, et personne d’autre que vous ne peut la fixer.
SourcesNorme internationale d'audit ISA 320, Materiality in Planning and Performing an Audit, International Auditing and Assurance Standards Board, handbook 2012, applicable aux audits des exercices ouverts à compter du 15 décembre 2009 · NIST/SEMATECH e-Handbook of Statistical Methods, section 6.3.1, What are Control Charts?, National Institute of Standards and Technology, DOI 10.18434/M32189, consulté le 13 août 2026
Le système change l'entreprise
AI-native finance function
Une fonction finance dont les circuits sont dessinés autour de l'IA dès le départ, et non une organisation ancienne à laquelle on ajoute un assistant.
Aussi : fonction finance native de l'IA, finance AI-native, AI-native finance
Le mot native est emprunté à l’informatique. Un logiciel dit cloud native n’est pas un vieux logiciel déplacé sur des serveurs loués. C’est un logiciel conçu pour cet environnement dès le départ, qu’on peut modifier souvent et sans drame, et dont on observe le fonctionnement en marche.
Transposé à la finance, ça donne une fonction dont on redessine les circuits autour de l’IA, au lieu d’une organisation existante à laquelle on ajoute un assistant. Sarah Friar, directrice financière d’OpenAI, en a tiré cinq leçons en août 2026. La plus transposable tient en une ligne : partir de la décision, pas de la tâche. On prend une décision qui compte, on remonte à l’envers tout le chemin qui y mène, les données, les validations, les allers-retours. Puis on regarde ce que la machine sait faire de ce chemin.
Ce que ça change quand on construit son système de pilotage tient dans l’écart entre deux projets. Automatiser la saisie fait gagner des heures de saisie. C’est visible, c’est mesurable, et ça ne change aucune décision. Deux heures par semaine, ça vaut quelques milliers d’euros par an. Redessiner le circuit qui mène au prix auquel vous signez une affaire touche la marge, et un point de marge sur un million d’euros de chiffre d’affaires en vaut dix mille. Le mot native ne dit pas qu’il y a de l’IA dedans, il dit que le circuit a été dessiné en la supposant.
Le prix à payer est la traçabilité. Chaque chiffre sorti doit remonter à une source, chaque écart porter son explication, chaque modification d’un budget validé passer par une autorisation. Sans ça, vous ne décidez pas plus vite, vous décidez plus vite sur du sable.
À ne pas confondre avec l’autonomie de la machine. Native ne veut pas dire que le logiciel décide. Dans ce que décrit Friar, la machine prépare, réconcilie et signale les exceptions. La finance vérifie, apporte son jugement, et signe. C’est elle qui reste responsable du chiffre.
SourcesSarah Friar, directrice financière d'OpenAI, What building an AI-native finance function taught me, publié le 10 août 2026 · Cloud Native Computing Foundation, CNCF Cloud Native Definition v1.1, approuvée le 26 février 2024
Zero-day close
Une clôture comptable dont le délai tombe à zéro, parce que le chiffre se réconcilie pendant la période au lieu de se reconstituer après.
Aussi : clôture à zéro jour, clôture continue, continuous close, clôture en continu
Le zero-day close, c’est une clôture comptable dont le délai tombe à zéro. Sarah Friar, directrice financière d’OpenAI, l’a fixé en août 2026 comme l’une des deux ambitions de son équipe, avec le prévisionnel réactualisé en continu. L’idée qu’elle met derrière : donner aux dirigeants une vue de la position financière en temps réel, réconciliée et traçable.
Elle ajoute une précision qu’on lit rarement. La clôture ne disparaît pas. Ce qui disparaît, c’est la course pour reconstituer l’activité une fois la période terminée. Le travail ne va donc pas plus vite, il change de moment. Il se fait pendant, au lieu d’après. Et elle écrit qu’ils n’y sont pas encore arrivés.
Ce que ça change quand on construit son pilotage commence par une question de droit. Le Code de commerce demande de contrôler par inventaire l’existence et la valeur du patrimoine de l’entreprise au moins une fois tous les douze mois. Une fois par an. Le rythme mensuel de votre clôture ne vient d’aucune obligation, il vient d’une habitude, et une habitude se change.
Prenez une PME qui sort son résultat de janvier autour du 20 février. Un poste d’achat qui dérape en janvier se voit en février, se discute en mars, et se répercute sur les prix de vente en avril. Trois mois passés à vendre à un prix calculé sur des coûts qui n’existent plus. Sur cent mille euros d’achats par mois et deux points d’écart, ça fait six mille euros qui ne reviendront pas. Ce qui coûte cher n’est pas la lenteur de la clôture, c’est l’âge du chiffre au moment où on décide dessus.
Le zéro est une direction, pas une cible à atteindre.
À ne pas confondre avec la clôture rapide, qui accélère le même travail au même endroit, en général en y mettant plus de monde pendant dix jours. Ni avec le suivi de trésorerie en temps réel. Votre solde bancaire est déjà en temps réel, et il ne vous dit ni votre marge, ni votre résultat.
Le mot sert dans Ce que je cherche vraiment en construisant mon système de pilotage financier.
SourcesSarah Friar, directrice financière d'OpenAI, What building an AI-native finance function taught me, publié le 10 août 2026 · Code de commerce, article L. 123-12, deuxième alinéa, version en vigueur depuis le 21 septembre 2000, Légifrance, consulté le 14 août 2026