L'effet WOW est le piège le plus dangereux des décisions sur l'IA.

Pourquoi la facilité nouvelle de produire une démonstration impressionnante a cessé d'être une preuve de qualité technologique, et ce qu'un associé devrait demander à la place

Résumé exécutif

Deux phénomènes se produisent simultanément dans l'expertise comptable. Les capacités des modèles d'intelligence artificielle progressent très vite, et la barrière à l'entrée pour fabriquer une démonstration informatique s'est effondrée. Une personne qui n'aurait pas su écrire un programme il y a trois ans peut aujourd'hui produire en quelques heures une interface convaincante, connecter des services et montrer un agent accomplissant une tâche apparemment complexe.

C'est une excellente nouvelle pour l'expérimentation. C'est aussi une machine à produire des illusions, pour une raison qui n'a rien de polémique : plus il devient facile de fabriquer quelque chose d'impressionnant, moins le caractère impressionnant constitue une information sur la qualité.

Je crois que nous confondons quatre objets distincts : faire fonctionner une chose une fois, construire un prototype, construire un produit, et construire une infrastructure capable de supporter une activité critique à grande échelle. La recherche sur les systèmes d'apprentissage automatique a établi que le code du modèle ne représente qu'une fraction minuscule d'un système réel, l'essentiel étant constitué de l'infrastructure qui l'entoure. Cette proportion ne s'est pas inversée avec les agents, elle s'est aggravée.

Trois mécanismes rendent la question spécifiquement comptable. Une chaîne agentique est à la fois complexe et fortement couplée, configuration dont la théorie de la fiabilité établit qu'elle produit des défaillances qui sont une propriété du système et non de ses opérateurs. Les modèles génératifs produisent des résultats plausibles et faux, catégorie d'erreur bien plus coûteuse que la panne visible. Et la contrainte économique se déplace : produire un résultat ne coûte presque plus rien, le vérifier coûte du temps de professionnel expérimenté.

J'en tire une conséquence pratique. Le bon indicateur n'est pas le taux d'automatisation mais le taux d'automatisation fiable, et la question à poser après chaque démonstration n'est pas de savoir si elle impressionne, mais ce qu'il y a derrière. Cette grille vaut pour la vidéo publiée un dimanche soir comme pour la présentation commerciale d'un éditeur installé.

Ce que la période a d'extraordinaire, et ce qu'elle produit d'illusoire

Je veux commencer par reconnaître ce qui est réellement remarquable, parce que la suite de cette note pourrait être lue comme une mise en garde conservatrice et qu'elle ne l'est pas.

La diffusion des modèles de langage transforme la production logicielle. Il est désormais possible de décrire un problème en langage naturel, d'obtenir du code, de le modifier par conversation, de connecter des services et d'obtenir un prototype fonctionnel en quelques heures. Un expert-comptable qui comprend parfaitement un problème métier peut matérialiser une idée sans attendre qu'une équipe de développement se libère.

Cela réduit massivement le coût de l'expérimentation, permet de tester des dizaines d'hypothèses, et rapproche le métier de la technologie. Je considère ce mouvement comme l'un des plus féconds de la période.

Le problème n'est donc pas le prototypage rapide. Il commence lorsqu'on tire de cette facilité une conclusion qui n'en découle pas, et qui s'énonce ainsi : puisque j'ai construit en cinq heures quelque chose qui fonctionne, le problème est résolu.

Ce qui a été démontré est qu'une solution peut exister. C'est une information réelle et c'est une information limitée.

Quatre objets qu'il faut cesser de confondre

Je propose une distinction que je crois nécessaire pour discuter sérieusement de ce sujet.

Faire fonctionner une chose une fois établit qu'elle n'est pas impossible. C'est le résultat d'une démonstration.

Construire un prototype établit qu'une suite d'opérations peut être enchaînée dans un environnement contrôlé. C'est le résultat d'un week-end de travail.

Construire un produit suppose qu'il fonctionne pour des utilisateurs qui ne sont pas son auteur, sur des données qu'il n'a pas choisies, de manière répétée, avec une documentation, une assistance et une gestion des versions.

Construire une infrastructure suppose en outre qu'il supporte une activité dont l'interruption est coûteuse, qu'il résiste aux pannes de ses dépendances, qu'il conserve une trace de ses actions, qu'il gère les habilitations et qu'il survive au changement de ses propres composants.

Ces quatre objets ne diffèrent pas par le degré de finition. Ils diffèrent par la nature du problème résolu, et le passage de l'un à l'autre n'est pas une amélioration progressive mais un changement de métier.

Le résultat qui devrait structurer la discussion

Il existe sur ce sujet un résultat de recherche que je trouve plus éclairant que tous les commentaires de marché, et qui est rarement cité dans la profession.

Sculley et ses coauteurs ont publié en 2015, à partir de l'expérience de systèmes d'apprentissage en production, une analyse de ce qu'ils nomment la dette technique cachée des systèmes d'apprentissage automatique. Leur constat principal se résume à une image devenue canonique : dans un système réel, le code consacré au modèle lui même ne représente qu'une petite fraction de l'ensemble, l'essentiel étant constitué de la collecte des données, de leur vérification, de l'extraction des caractéristiques, de la gestion des configurations, de la surveillance, de la gestion des ressources, de l'infrastructure de service et des outils d'analyse.

Leur seconde proposition est plus dérangeante. Les systèmes d'apprentissage contractent une dette technique d'une nature particulière, parce qu'ils ajoutent aux difficultés du logiciel classique des difficultés propres : l'enchevêtrement des signaux, les dépendances de données instables, les boucles de rétroaction cachées, et le principe qu'ils résument en disant que changer n'importe quoi change tout, puisqu'aucune entrée n'est réellement indépendante des autres.

Je retiens de ces travaux une conclusion simple. L'intelligence n'a jamais été la partie la plus coûteuse d'un système d'intelligence artificielle. Et le passage aux agents n'a pas inversé cette proportion : il l'a aggravée, puisqu'un agent ajoute l'orchestration, l'appel d'outils, la gestion d'état et l'autonomie de décision à un système qui était déjà majoritairement constitué d'infrastructure.

Ce qu'une démonstration démontre, et ce qu'elle ne démontre pas

Prenons le cas le plus fréquent. Un agent reçoit une facture, identifie le fournisseur, extrait le montant, reconnaît la taxe, propose un compte et génère une écriture. La démonstration dure trente secondes et elle est spectaculaire.

Le spectateur voit un enchaînement et son esprit complète ce qu'il n'a pas vu. Il en conclut que la technologie peut remplacer la production comptable.

Ce qui a été établi est précis : dans les conditions de la démonstration, sur cette pièce, dans cet environnement, à cet instant, le système a produit le résultat attendu.

N'ont pas été établis le comportement sur la distribution réelle des situations rencontrées par un cabinet, le taux d'erreur sur des données jamais vues, la stabilité dans le temps, le comportement après une mise à jour du modèle sous-jacent, le coût unitaire à l'échelle, le temps de réponse en charge, la reprise après interruption, l'intégration au système d'information existant, la gestion des habilitations, la traçabilité des actions, la capacité d'expliquer une écriture produite, et surtout la détection par le système de ses propres incertitudes.

Je ne reproche pas à une démonstration de ne pas établir ces points : ce n'est pas sa fonction. Je constate que l'auditoire conclut comme si elle les avait établis, et que cette inférence est fausse.

Pourquoi notre jugement se trompe

L'effet est cognitif avant d'être technique, et il mérite d'être nommé.

Lorsque nous voyons une machine accomplir une tâche que nous pensions difficile, nous réévaluons immédiatement l'ensemble du problème, parce que nous inférons la difficulté d'un système de la difficulté que nous éprouverions nous mêmes à exécuter la tâche. Ce raisonnement, qui fonctionne entre humains, ne fonctionne pas avec des machines dont le profil de compétence ne ressemble pas au nôtre.

Un second mécanisme s'y ajoute et il est propre à la période. L'interface masque la complexité. On écrit une phrase et un tableau apparaît. La complexité apparente de l'usage est devenue presque nulle.

Or il faut distinguer deux grandeurs que la simplicité de l'interface conduit à confondre. La complexité d'utilisation, qui s'effondre. Et la complexité d'industrialisation, qui demeure et qui augmente, parce qu'un système probabiliste est plus difficile à observer, à tester et à reproduire qu'un programme déterministe. Un même enchaînement d'instructions ne produit pas nécessairement le même chemin d'exécution, ce qui prive l'ingénieur du test le plus élémentaire dont il disposait.

Je crois que cette confusion entre la simplicité du prompt et la simplicité du problème sera l'une des erreurs structurantes des prochaines années.

Une chaîne agentique est un système fortement couplé

La théorie de la fiabilité fournit le cadre qui me paraît le plus juste pour caractériser le risque, et je ne l'ai pas vu mobilisé dans ce débat.

Perrow a montré que les systèmes présentant simultanément deux propriétés produisent des défaillances qu'il qualifie de normales, au sens où elles sont une conséquence de leur conception et non d'une faute de leurs opérateurs. La première propriété est la complexité interactive, c'est-à-dire l'existence d'interactions non anticipées entre composants. La seconde est le couplage serré, c'est-à-dire l'absence de délai, de marge ou de stock entre les étapes, qui empêche d'intervenir avant que la conséquence ne se propage.

Une chaîne agentique réunit exactement ces deux propriétés. Les étapes interagissent par un état partagé que le concepteur n'a pas entièrement spécifié, puisque le modèle décide d'une partie de son propre enchaînement. Et elles s'exécutent sans marge, chaque sortie devenant immédiatement l'entrée de la suivante.

La conséquence pratique est importante. Allonger une chaîne agentique ne modifie pas seulement le niveau de risque, elle modifie sa classe : au delà d'un certain nombre d'étapes couplées, les défaillances cessent d'être des événements identifiables pour devenir des propriétés du système. C'est la raison pour laquelle les architectures les plus solides que j'observe privilégient des enchaînements courts, des points d'arrêt explicites et des marges introduites volontairement, plutôt que l'autonomie maximale.

Le calcul en chaîne, posé correctement

On rencontre fréquemment l'illustration suivante : si chaque étape d'un enchaînement de cent opérations réussit dans quatre-vingt-dix-neuf pour cent des cas, la probabilité que les cent réussissent ensemble est d'environ trente-six pour cent.

Ce calcul est exact et son hypothèse est fausse, puisque les étapes ne sont pas indépendantes. Je préfère énoncer ce qu'il illustre correctement et ce qu'il n'établit pas.

Ce qu'il illustre est une propriété réelle : la fiabilité d'un composant pris isolément ne renseigne pas sur la fiabilité de la chaîne qui l'emploie, et l'intuition sous-estime systématiquement l'effet de l'accumulation.

Ce qu'il n'établit pas est le taux réel, parce que la corrélation entre les défaillances peut jouer dans les deux sens. Des erreurs corrélées peuvent se compenser, un dossier mal interprété produisant une erreur cohérente et donc détectable. Elles peuvent aussi se renforcer, une mauvaise interprétation initiale contaminant toutes les étapes suivantes qui la tiennent pour acquise. Ce second cas est le plus fréquent dans les chaînes agentiques et c'est le plus dangereux, puisque le système produit alors un résultat cohérent et faux.

Je retiens donc que la grandeur à surveiller n'est pas le taux de défaillance mais le taux de détection, ce qui me conduit au point suivant.

L'erreur silencieuse et l'asymétrie économique

Dans un système classique, la plupart des défaillances sont visibles : une interface renvoie une erreur, un programme s'interrompt, un champ obligatoire manque, un calcul échoue.

Les modèles génératifs introduisent une catégorie différente et bien plus coûteuse : le résultat plausible mais faux. L'autorité française de protection des données le formule nettement en rappelant que ces systèmes fonctionnent de manière probabiliste, peuvent produire des informations inexactes tout en donnant une impression de plausibilité, et qu'une confiance excessive sans vérification conduit à des décisions erronées.

En comptabilité, cette propriété est déterminante. Le pire agent n'est pas celui qui déclare ne pas savoir. C'est celui qui produit avec assurance une écriture crédible et incorrecte, puisque le coût de détection d'une erreur crédible est sans commune mesure avec celui d'une erreur manifeste.

J'en tire une proposition économique que je crois centrale et qui est rarement formulée.

Le coût de production d'un résultat tend vers zéro. Le coût de vérification, lui, ne diminue pas : il exige du temps de professionnel expérimenté, et il augmente même avec la qualité du système, puisqu'un résultat manifestement faux s'écarte immédiatement tandis qu'un résultat subtilement faux exige une revue approfondie. La contrainte se déplace donc de la production vers la vérification, et l'économie d'un système agentique est l'économie de sa fonction de contrôle.

Bainbridge avait formulé en 1983 la difficulté supplémentaire que cette configuration produit, sous le nom d'ironies de l'automatisation. Le concepteur automatise ce qu'il sait automatiser et laisse à l'opérateur le résidu, c'est-à-dire la surveillance et les cas irréguliers, pour lesquels l'attention humaine est mal adaptée. Et la compétence de cet opérateur se dégrade précisément parce qu'il ne pratique plus l'exécution dont dépend sa capacité de contrôle.

Appliquée à un cabinet, cette observation signifie que la vérification des productions automatisées exige le maintien délibéré de la compétence que l'automatisation remplace. C'est un coût récurrent qu'aucune évaluation de projet n'intègre, et son omission produit un gain immédiat suivi d'une dégradation différée de la capacité de contrôle.

En comptabilité, l'exception est le produit

Je crois que la spécificité du métier tient en une phrase : la valeur d'un système de production comptable ne réside pas dans sa capacité à traiter les situations normales mais dans sa manière de traiter les autres.

Les démonstrations montrent presque toujours le chemin heureux. Une facture lisible, un fournisseur connu, un montant identifiable, une taxe classique, un exercice régulier.

Le métier réel est plus hétérogène : factures étrangères, avoirs, doublons, acomptes, immobilisations, fournisseurs nouveaux, dates incohérentes, pièces manquantes, taxe sur les encaissements, ventilations analytiques, exercices décalés, opérations intragroupe, imports bancaires imparfaits, conventions propres au dossier, changements de plan comptable, pièces de mauvaise qualité.

Le produit n'est donc pas la capacité de comptabiliser une pièce. Le produit est la capacité de déterminer quand comptabiliser automatiquement, quand demander une information complémentaire, quand faire prévaloir une règle déterministe, quand bloquer, quand transmettre à un humain, et de conserver la trace de chacune de ces décisions.

Ce n'est plus du prompting. C'est de l'architecture, et c'est une architecture dont la partie la plus coûteuse à construire est précisément celle que la démonstration ne montre jamais.

Le bon indicateur n'est pas le taux d'automatisation

J'en viens à la conséquence la plus directement utilisable.

Comparons deux solutions. La première automatise quatre-vingt-dix-huit pour cent des opérations, mais une partie des deux pour cent restants produit des erreurs non détectées. La seconde automatise quatre-vingt-cinq pour cent des opérations et identifie presque systématiquement les quinze pour cent qui exigent une intervention.

Dans un environnement comptable, la seconde est supérieure, et elle l'est même largement. La première transfère au cabinet un risque qu'il ne voit pas, et la responsabilité professionnelle demeure entière.

La grandeur pertinente n'est donc pas le taux d'automatisation mais le taux d'automatisation fiable, c'est-à-dire la part des opérations traitées sans intervention et dont l'exactitude est assurée.

J'ajoute une notion qui me paraît décisive et que les discussions de marché ignorent : la calibration. Un système est calibré lorsque la confiance qu'il déclare correspond à sa probabilité d'avoir raison. Un système calibré à quatre-vingt-cinq pour cent d'automatisation est exploitable, parce qu'il permet d'organiser le contrôle là où il est utile. Un système non calibré, même plus performant en moyenne, ne l'est pas, puisqu'il ne permet pas de savoir où regarder.

Le taux d'automatisation produit d'excellentes démonstrations. La calibration produit de bons systèmes.

Ce qu'est réellement un système

Un prompt peut être excellent et ne constitue qu'un élément parmi une quinzaine.

Un système industriel suppose de répondre à des questions qui portent sur les données et leur normalisation, sur l'identité et les habilitations, sur l'intégration avec les logiciels existants, sur l'orchestration des opérations, sur l'affectation des modèles aux tâches, sur les décisions qui doivent demeurer déterministes, sur la détection des sorties aberrantes, sur le traitement du doute, sur la traçabilité, sur l'observabilité et la détection des dérives, sur la sécurité et la limitation des accès, sur la résilience en cas d'indisponibilité d'un service, sur la réversibilité des opérations, sur l'évaluation avant chaque version, et sur le moment où l'humain reprend la main.

Les fournisseurs de modèles décrivent d'ailleurs un agent dans ces termes et non dans ceux du prompt : un modèle, des outils, des instructions, auxquels s'ajoutent des garde-fous, une authentification, des contrôles d'accès et des mécanismes d'intervention humaine pour les situations sensibles. Les recommandations publiques en matière de sécurité des systèmes d'intelligence artificielle énumèrent de leur côté le contrôle des accès, le cloisonnement des données, la gestion des versions, la revue du code, la maintenance, la gestion des vulnérabilités et la journalisation des sorties. Les cadres de gestion des risques retiennent la validité, la fiabilité, la sécurité, la résilience, la responsabilité, la transparence et la protection des données comme caractéristiques à considérer sur l'ensemble du cycle de vie.

Aucun de ces documents ne traite du prompt comme de la question centrale, et je crois que c'est le signal le plus clair que le marché pourrait recevoir.

Le prototypage rapide n'est pas l'ennemi

Je tiens à écarter le procès caricatural, parce qu'il est fréquent et qu'il est faux.

La programmation assistée par conversation est remarquablement efficace pour fabriquer une maquette, tester une hypothèse, automatiser un traitement personnel, construire un outil interne de faible criticité, ou accélérer le travail d'une équipe d'ingénierie constituée.

Le problème apparaît lorsqu'une méthode de prototypage est transformée en doctrine d'industrialisation. Affirmer qu'une chose a été construite en cinq heures est une information intéressante. Affirmer que cela démontre l'obsolescence des infrastructures existantes est une extrapolation qui ne découle pas de la première proposition.

Je note d'ailleurs que les équipes qui construisent ces technologies tiennent un discours plus prudent que leurs commentateurs : elles soulignent que l'on peut aller loin avec des tests manuels et de l'intuition pendant les premières phases, et que la difficulté apparaît au passage à l'échelle, lorsque l'absence d'évaluations structurées conduit à découvrir les défaillances directement en production.

La comparaison destructrice, et pourquoi elle vise aussi les éditeurs

Une conséquence économique de cette période est moins discutée et je la crois sérieuse.

Un dirigeant de cabinet voit une vidéo de quatre-vingt-dix secondes annonçant que la production comptable a été remplacée en un après-midi. Il regarde ensuite son propre projet d'intégration, qui dure depuis neuf mois, coûte cher, mobilise des consultants et comporte des fonctionnalités imparfaites. Le contraste est violent et il peut en conclure que son prestataire lui raconte des histoires.

Les deux ne résolvent pas le même problème. Le premier a construit une démonstration. Le second doit garantir un service pour des centaines d'entreprises, conserver les données, gérer les droits, supporter les mises à jour, assurer la continuité et traiter les exceptions. Comparer les deux revient à comparer une maquette de pont posée sur une table et un ouvrage sur lequel passent cinquante mille véhicules par jour. La maquette peut être brillante, personne ne lui demande de supporter les camions.

Je veux cependant énoncer la conséquence symétrique, faute de quoi cette note défendrait une position plutôt qu'un raisonnement.

La grille que je propose ne vise pas les nouveaux entrants, elle vise les démonstrations. Or la présentation commerciale d'un éditeur installé est également une démonstration, conduite sur un jeu de données choisi, dans un environnement maîtrisé, par une personne qui connaît le chemin. Les mêmes questions doivent lui être posées, et un acteur historique qui refuse de communiquer son taux d'erreur sur des données jamais vues se trouve exactement dans la même situation que l'auteur de la vidéo.

L'ancienneté n'est pas une preuve de robustesse, elle est une présomption. Comme toute présomption, elle se vérifie.

Plus le modèle devient puissant, plus l'infrastructure compte

On pourrait croire l'inverse, et c'est ce qui rend ce point contre-intuitif.

Si les modèles deviennent capables de l'essentiel du raisonnement nécessaire à la production comptable, le problème ne disparaît pas : il se déplace. La question cesse d'être de savoir si le système comprend une facture pour devenir celle de savoir comment faire fonctionner cette compréhension dans un environnement réel.

Il faut lui fournir les bonnes données, le bon contexte, les bonnes autorisations, les bons outils, les bonnes règles, les bonnes limites et les bons mécanismes de validation, puis observer son comportement dans la durée.

Et il y a une raison économique supplémentaire. Un modèle accessible à tous les acteurs du marché aux mêmes conditions ne procure aucun avantage durable à aucun d'eux : il élève le niveau de référence de l'ensemble. L'avantage se déplace donc vers ce qui n'est pas accessible de la même manière : les données structurées, l'historique, les intégrations, les règles métier accumulées, la connaissance des exceptions, les systèmes d'évaluation et l'architecture.

Le modèle est peut-être le cerveau. Une entreprise ne fonctionne pas avec un cerveau posé sur une table.

Savoir où ne pas employer l'intelligence artificielle

Un signe de maturité d'une architecture me paraît plus révélateur que tous les autres : la capacité de son concepteur à désigner les endroits où il a choisi de ne pas employer de modèle.

Une écriture parfaitement déterminable n'a aucune raison d'être confiée à un système probabiliste. Un calcul de taxe dont la règle est explicite doit être exécuté par cette règle. Un contrôle de cohérence arithmétique n'exige aucun raisonnement.

L'intelligence doit intervenir là où elle apporte quelque chose, c'est-à-dire là où la règle est incomplète, ambiguë ou contextuelle. Le déterminisme doit demeurer là où il est supérieur, c'est-à-dire là où il est vérifiable, reproductible et explicable.

Un fournisseur qui emploie un modèle partout démontre moins sa modernité que son absence d'architecture.

Les questions que je poserais

Je substituerais à la question de savoir si une démonstration est impressionnante cinq familles de questions, qui ne sont pas spectaculaires et qui sont les seules informatives.

Sur le périmètre de test : sur combien de dossiers le système a-t-il été éprouvé, quel est son taux de réussite sur des données jamais vues, et quelle est sa performance sur les cas limites plutôt que sur la moyenne.

Sur la détection : comment les erreurs sont-elles mesurées, comment les erreurs silencieuses sont-elles identifiées, le système sait-il déclarer son incertitude, et cette incertitude déclarée correspond-elle à sa probabilité réelle de se tromper.

Sur l'architecture : quelles décisions demeurent déterministes, quels garde-fous encadrent le modèle, que se passe-t-il lorsqu'il doute, et qui reprend la main lorsqu'il sort de son domaine de confiance.

Sur la sécurité et la trace : où sont stockées les données, lesquelles sont transmises au fournisseur du modèle, comment fonctionnent les habilitations, toutes les actions sont-elles tracées, peut-on revenir en arrière, et que se passe-t-il si un service devient indisponible.

Sur l'exploitation dans la durée : existe-t-il une suite d'évaluations, chaque nouvelle version est-elle testée contre les précédentes, que se passe-t-il lorsque le modèle sous-jacent change, et quel est le coût par dossier à l'échelle visée.

Je ne connais pas de fournisseur sérieux que ces questions embarrassent, et c'est précisément ce qui en fait un filtre.

Le risque de détruire la confiance

Il existe enfin un enjeu collectif, et je crois qu'il est sous-estimé.

Surpromettre aujourd'hui risque de ralentir l'adoption demain. Si l'on explique pendant deux ans à la profession que tout est simple, que quelques prompts suffisent et que les infrastructures existantes sont obsolètes, puis que les premiers déploiements rencontrent des difficultés de qualité, d'intégration et de sécurité, le marché passera brutalement de l'enthousiasme au scepticisme.

Ce serait dommageable, parce que la transformation est réelle. Il faut donc tenir simultanément deux propositions qui ne sont contradictoires qu'en apparence : l'intelligence artificielle va bouleverser la production comptable, et construire une infrastructure de production comptable agentique sera extraordinairement difficile.

Je ne vois aucune contradiction entre ces deux énoncés. Je vois une période pendant laquelle ceux qui les tiennent ensemble prendront de l'avance sur ceux qui n'en tiennent qu'un.

Ce que je n'affirme pas

Je n'affirme pas que les démonstrations soient trompeuses. Elles établissent une possibilité, ce qui est une information réelle, et le problème réside dans l'inférence qu'en tire l'auditoire.

Je n'affirme pas que les infrastructures existantes soient supérieures. Elles portent leur propre dette, et une part de leur complexité procède de choix anciens plutôt que d'exigences de robustesse. La grille que je propose leur est applicable au même titre.

Je n'affirme pas que les agents échoueront. Je crois au contraire qu'une part considérable du travail de production sera réalisée par des systèmes agentiques, et ma thèse porte sur ce qu'il faudra construire autour, non sur la faisabilité.

Je n'affirme pas enfin que les ordres de grandeur que j'ai employés soient mesurés. Le calcul en chaîne est une illustration dont j'ai exposé la limite, et la comparaison entre deux taux d'automatisation est une construction destinée à isoler une propriété, non une observation.

Ce qu'il faut demander après chaque démonstration

Je résume en trois propositions.

La facilité nouvelle de produire une démonstration impressionnante a détruit la valeur informative du caractère impressionnant. Lorsque fabriquer une illusion coûte quelques heures, être impressionné ne renseigne plus sur la qualité de ce qu'on observe, et il faut reconstruire d'autres critères.

Ces critères portent sur ce que la démonstration ne montre pas : le comportement sur la distribution réelle des situations, la détection des erreurs, la calibration de l'incertitude, les garde-fous déterministes, la traçabilité, la sécurité et le coût à l'échelle. La recherche sur les systèmes d'apprentissage a établi de longue date que le modèle ne constitue qu'une fraction minuscule d'un système réel, et les agents ont accentué cette disproportion.

La contrainte économique s'est déplacée de la production vers la vérification. Produire un résultat ne coûte presque plus rien, le vérifier coûte du temps de professionnel expérimenté, et ce temps est la ressource rare. Un système qui automatise davantage sans améliorer la détection ne libère donc pas de capacité, il en consomme.

Après chaque démonstration, je poserais donc une seule question supplémentaire, et je crois qu'elle suffit à distinguer ceux qui ont construit un système de ceux qui ont construit une vidéo. Très bien. Montrez-moi maintenant ce qu'il y a derrière.