Les données ne suffisent pas

Je commence par une scène que vous reconnaîtrez peut-être.

Une entreprise qui a fait ses devoirs décide de prendre l'intelligence artificielle au sérieux. Et les devoirs ont été faits : le data lake est mature, les référentiels ont été unifiés, le catalogue documente les colonnes, la traçabilité, les API. Le pilote n'est pas trivial non plus : un agent qui analyse des projets de contrat au regard des politiques de la maison, signale les écarts et propose une rédaction corrigée. L'équipe est bonne et les tests dépassent les attentes. Six mois plus tard, le projet est pourtant à l'arrêt, et la raison n'apparaît dans aucun log : personne n'a su répondre à trois questions de fond. Comment savons-nous que l'analyse est juste ? Que se passe-t-il quand elle est fausse ? Qui en répond ?

La scène n'est pas l'exception ; c'est le cas typique. Selon IDC, 88 % des preuves de concept d'IA n'atteignent jamais la production : sur 33 POC lancés par une entreprise, quatre deviennent des systèmes en exploitation ^[1]. Et quand on demande à ceux qui construisent ce qui bloque, la réponse numéro un n'est ni le coût, ni les talents, ni l'intégration : c'est la qualité. Dans la plus grande enquête menée à ce jour auprès d'ingénieurs d'agents (LangChain, 1 340 répondants, fin 2025), la qualité et la fiabilité arrivent en tête des blocages avec 32 %, devant la latence et la sécurité ^[2] ; et les DSI interrogés par a16z résument la raison avec une franchise peu commune : assurer la qualité des agents « n'est pas exactement facile » ^[3]. Je traduis : les entreprises ont construit des systèmes dont elles ne savent pas vérifier les réponses. Et elles s'étonnent du résultat.

L'échelle à trois marches

Il y a dix ans, le diagnostic pour tout échec numérique était « organisez vos données », et le marché a obéi : data lakes, intégrations, nettoyage des référentiels. Puis le diagnostic est monté d'un ton : « documentez vos données », et le marché a obéi de nouveau. Catalogues, dictionnaires, spécifications d'API, traçabilité des données. Si vous travaillez dans ce domaine, vous savez qu'une bonne partie des moyennes et grandes entreprises a déjà franchi, raisonnablement, ces deux étapes. C'est pourquoi je ne vais pas vous dire qu'il reste à organiser vos données ; ce serait insulter votre travail avec un conseil de 2015.

Ce que je vais dire est plus inconfortable : l'échelle a une troisième marche, et c'est là que le pilote meurt. Organiser les données était la première ; les documenter, la deuxième ; formaliser la connaissance est la troisième, et presque personne ne l'a gravie, parce que jusqu'à récemment elle passait pour un luxe académique.

La différence entre la deuxième et la troisième marche tient en une phrase : la documentation décrit ; la formalisation vérifie. Le catalogue dit ce que signifie la colonne, le dictionnaire dit ce que contient le champ, la spécification dit ce qu'attend l'API. Tout cela est de la prose destinée à des humains. Rien de tout cela n'est capable de l'acte que l'ère des modèles probabilistes exige le plus : refuser. Un catalogue de données ne sait pas dire non. Et tout le problème posé par les LLM, comme nous le verrons, se résume à disposer, à chaque point critique, de quelque chose ou de quelqu'un qui sache dire non.

Le monde des données lui-même, d'ailleurs, a déjà commencé à inventer la troisième marche sans lui donner ce nom. Data contracts, validation de schéma, tests de pipeline ; des artefacts dont la seule fonction est de rejeter ce qui arrive erroné. L'instinct est juste. Il reste à reconnaître que ce n'est pas une fonctionnalité d'ingénierie des données ; c'est l'embryon d'une autre discipline.

Ce que la documentation ne contient pas

Car pensez à ce que votre entreprise sait vraiment, et comparez avec ce qu'elle a documenté.

Elle sait que ce gros client accepte un retard de livraison, mais ne tolère aucune surprise sur le prix. Elle sait qu'un certain type de contrat exige une clause qui ne figure dans aucun modèle, parce qu'un procès d'il y a huit ans a enseigné la leçon par la méthode coûteuse. Elle sait quelle remise le vendeur accorde seul, laquelle exige une validation et laquelle jamais, même si le système le permet. Dans quel catalogue cela se trouve-t-il ? Dans aucun. On a documenté la donnée ; on n'a pas formalisé la règle, l'exception, la limite, le sens. Michael Polanyi a donné un nom à ce résidu il y a soixante ans : la connaissance tacite, résumée dans la formule que tout dirigeant devrait avoir au mur : nous savons plus que nous ne pouvons dire ^[4]. Les données, même impeccablement documentées, enregistrent ce qui s'est passé ; la connaissance dit ce que les choses signifient, comment elles se relient et ce qu'il faut en faire.

Jusqu'à récemment, cette lacune ne faisait pas mal : il y avait toujours un humain dans la boucle pour la combler avec du bon sens. L'IA générative supprime cette marge.

Le sophiste parfait

Les modèles de langage sont une conquête technique extraordinaire ; rien ici n'est du scepticisme de supporter adverse. Mais deux caractéristiques doivent être dites sans euphémisme, parce qu'aucune nouvelle version ne les élimine. Qui les omet ne simplifie pas ; il vend.

Première : l'indéterminisme est constitutif, ce n'est pas un bug. Un LLM est une machine probabiliste ; la même question peut produire des réponses différentes. Attendre « le modèle qui ne se trompe pas » est la stratégie de qui n'a pas compris l'instrument qu'il a acheté.

Deuxième, et plus grave : l'erreur arrive impeccablement écrite. Le défaut spécifique du LLM n'est pas de se tromper ; les machines et les gens se trompent. C'est que la fluidité s'est détachée de la vérité : le texte faux sort avec la même syntaxe élégante, la même assurance de ton, la même mise en forme professionnelle que le texte juste. Platon a connu ce personnage il y a vingt-quatre siècles. Dans le Gorgias, le rhéteur se vante d'être plus persuasif que le médecin, devant la foule, en matière de médecine, sans connaître la médecine ^[5] ; la persuasion comme expertise autonome, découplée de la connaissance. Le LLM est le sophiste parfait : il parle avec autorité de n'importe quoi, et l'autorité du ton n'a aucun rapport interne avec la vérité du contenu. Et Borges, comme d'habitude, est arrivé le premier au reste : dans « Tlön, Uqbar, Orbis Tertius », un article d'encyclopédie sur un pays qui n'existe pas est formellement indiscernable de la véritable érudition ; et la cohérence de l'invention est si séduisante que la réalité lui cède peu à peu. « La realidad cedió en más de un punto. Lo cierto es que anhelaba ceder » ^[6] : la réalité a cédé parce qu'elle aspirait à céder. La citation hallucinée que le modèle fabrique, avec un auteur plausible, une revue plausible et une année plausible, est un article de Tlön ; et l'entreprise qui l'accepte sans vérifier est la réalité aspirant à céder.

Réunissez les deux caractéristiques. Un système qui se trompe de façon imprévisible, en écrivant l'erreur avec une perfection persuasive, est inutilisable sans une contrepartie qui vérifie. Et notez ce que le LLM ne peut pas offrir, par construction : le jugement. Juger, c'est répondre de la réponse : nom, fonction, conséquence. La responsabilité n'est pas une fonction que l'on optimise ; c'est une place que l'on occupe. Il n'y a personne à l'intérieur du modèle. « C'est l'IA » n'est pas une défense ; c'est l'aveu qu'on a automatisé précisément ce qui ne se transfère pas.

La bonne nouvelle, pour qui gravit la marche

Nous savons vivre avec des instruments qui se trompent ; l'ingénierie ne fait rien d'autre depuis des siècles. On n'exige pas de l'instrument l'infaillibilité : on entoure l'instrument de vérification. La bonne question n'a jamais été « quand le modèle cessera-t-il de se tromper ? ». C'en est une autre : qu'est-ce qui, dans mon processus, me permet de savoir si cette réponse est juste, et à quel coût ?

Là où existe une règle claire (un prix, un délai, une clause obligatoire), la vérification peut être automatique et bon marché ; les règles énumérables appartiennent au code, qui est déterministe et auditable, pas au modèle. Là où la lecture exige du contexte et du jugement, l'hypothèse du modèle passe par quelqu'un qui peut la ratifier. Et là où même cela n'est pas possible, on découvre quelque chose d'aussi précieux : ce qui ne se délègue pas.

Mais remarquez le prérequis : pour vérifier, il faut avoir de quoi vérifier. Les règles doivent être explicites ; le vocabulaire, partagé ; le « nous avons toujours fait ainsi » doit devenir un critère contrôlable. C'est la troisième marche de l'échelle. Quand ce travail est fait, le résultat porte un nom technique qui effraie plus qu'il ne devrait : ontologie. Pas celle de la métaphysique, bien que telle soit sa généalogie ; une ontologie d'entreprise est quelque chose de presque prosaïque : l'accord explicite sur les entités qui existent dans votre activité, sur leurs noms, sur leurs relations et sur les règles qui les gouvernent ^[7]. C'est la différence entre « nous avons les données des contrats, documentées » et « nous savons ce qu'est un contrat pour nous, ce que chaque type exige, et une machine peut vérifier si ce projet est conforme ».

C'est pourquoi l'opportunité qu'ouvre l'IA n'est pas d'abord technologique ; elle est triple. Technologique, bien sûr : des systèmes qui combinent la flexibilité des modèles avec la fiabilité de règles explicites et de vérificateurs. Méthodologique : redessiner les processus en demandant, étape par étape, ce qui est règle, ce qui est interprétation, ce qui exige un humain responsable. Et culturelle, la plus difficile : installer l'habitude d'expliciter ce que l'on sait ; traiter la connaissance de la maison comme un actif qui se construit et se révise, et non comme un folklore qui habite une demi-douzaine de têtes et franchit la porte avec elles.

Pourquoi « continue »

Le nom de la série est un parallèle délibéré avec le génie logiciel. Il fut un temps où intégrer du logiciel était un événement : trimestriel, traumatisant, cérémonieux. L'intégration continue a transformé l'événement en pratique quotidienne, par petits morceaux, avec vérification à chaque pas.

Je défends le même virage pour la connaissance. « Nous avons fait notre ontologie en 2026 » est une phrase aussi absurde que « nous avons fait notre intégration en 2019 ». L'activité change ; les exceptions d'hier deviennent les règles de demain. Ce que l'on construit, c'est le processus permanent : capturer, expliciter, structurer, réviser. Et qui le construit ne devient pas seulement « prêt pour l'IA » ; il devient meilleur en tout, parce qu'il décide mieux, forme mieux et dépend moins de la mémoire héroïque des vétérans.

Ce qui vient

La série aura trois mouvements. Dans le premier, les lacunes : l'indéterminisme vu de l'intérieur, avec le défilé des atténuations que l'industrie a inventées et ce qu'elles avouent ; la distinction entre décider, interpréter et répondre ; et la lacune à l'échelle de l'organisation, quand tout le monde produit plus que jamais et que personne ne sait qui a vérifié quoi. Dans le deuxième, formaliser : connaissance tacite et explicite ; ce qu'est une ontologie d'entreprise en pratique ; qui l'écrit, avec quels rôles et quels rituels ; et ce que l'usage de l'IA fait à la compétence de ceux qui l'utilisent. Dans le troisième, déléguer : pourquoi copier l'organigramme sur les agents est l'erreur d'architecture la plus courante ; pourquoi l'autonomie se conquiert par la preuve, et ce que les agents qui ne s'éteignent jamais portent avec eux ; à qui doit appartenir la connaissance formalisée ; et, pour finir, le portrait de l'entreprise qui émerge de tout cela.

Un essai toutes les deux semaines, en portugais et en anglais ; quand je spéculerai, je dirai que je spécule.

Je termine comme tous les essais de cette série se termineront : par une question en deux temps. Choisissez un processus important de votre entreprise et demandez : combien de ce qui fait fonctionner ce processus est écrit quelque part ? Et, de ce qui est écrit, combien une machine pourrait-elle utiliser pour dire non ?

Connaissance Continue est une série de Life After AI.