Bâtir pour le mauvais modèle

Tous les déploiements d’IA en entreprise dont j’ai lu la description depuis six mois partagent la même architecture. Une épaisse couche d’échafaudage de prompts pour compenser la confusion du modèle. Un pipeline de récupération pour donner à la petite cuillère le contexte que le modèle ne sait pas trouver lui-même. Des règles d’affaires codées en dur parce que le modèle n’arrive pas à les inférer de façon fiable. Des garde-fous procéduraux boulonnés après coup, parce que le modèle a fait quelque chose d’inattendu en production. Des portillons de révision humaine à chaque étape, parce que personne ne fait assez confiance au résultat pour le laisser partir.

Cette architecture est rationnelle. Elle reflète les modèles que nous avons aujourd’hui. Elle signifie aussi que l’essentiel de l’investissement des entreprises en IA ne bâtit pas de la capacité. Il bâtit de la compensation. Et la compensation a une date de péremption.

Les aspérités disparaissent

Claude Mythos a trouvé dans OpenBSD un bogue vieux de 27 ans qui avait survécu à des décennies de révision humaine. Il a produit 181 exploits fonctionnels contre Firefox, là où le meilleur modèle précédent en avait réussi deux. Il n’a pas été entraîné pour la cybersécurité. Il a été entraîné à comprendre le code en profondeur, et la capacité en sécurité a émergé comme un effet secondaire d’un raisonnement de qualité.

Ce n’est pas une amélioration incrémentale. C’est le genre de saut qui rend inutiles des catégories entières d’échafaudage. Un modèle qui raisonne aussi bien sur le code n’a pas besoin d’un prompt procédural de 3 000 jetons lui disant de classifier l’intention, puis de vérifier les URL hallucinées, puis de valider contre la base de connaissances. Il a besoin de connaître l’objectif et les contraintes. Le reste, il peut le déduire.

Les aspérités autour desquelles nous bâtissons depuis deux ans, les hallucinations, les limites de la fenêtre de contexte, l’incapacité à suivre des processus en plusieurs étapes de façon fiable, ne sont pas des caractéristiques permanentes de l’IA. Ce sont des symptômes de la capacité actuelle des modèles. Et la capacité actuelle des modèles est sur le point de changer de façon marquée.

Le problème des investissements échoués

Voici le motif inconfortable. Plus une organisation a investi pour compenser les limites des modèles, plus il lui sera difficile de tirer parti de modèles qui n’ont plus ces limites.

Ce prompt système de 3 000 jetons n’est pas seulement inutile avec un modèle plus intelligent. Il est activement nuisible. Il surcontraint le modèle, l’enferme dans des étapes procédurales dont il n’a plus besoin, et gaspille la fenêtre de contexte en instructions qu’un modèle plus capable gérerait implicitement.

Je l’ai appris à la dure. J’avais bâti pour mon flux de développement une compétence de planification élaborée : des commandes SDLC détaillées, des procédures étape par étape, des phases structurées. Un jour, j’ai oublié de l’invoquer. Claude a mieux planifié le travail sans elle qu’il ne l’avait jamais fait avec. La procédure détaillée n’aidait pas. Elle microgérait. J’ai fini par jeter la plupart des commandes que j’avais bâties.

La leçon se généralise. L’IA ressemble de plus en plus à des gens compétents. Nous ne microgérons pas les étapes d’implémentation d’une ingénieure sénior. Nous lui disons ce dont nous avons besoin et pourquoi c’est important, et elle trouve le comment. Elle choisit les outils, la séquence, l’architecture. C’est exactement ce que font maintenant les modèles capables quand nous nous enlevons du chemin. Chaque instruction procédurale que nous laissons dans le prompt est un vote de non-confiance envers un système qui n’en a plus besoin.

Le même motif se répète à travers toute la pile. Les pipelines RAG complexes qui prédécoupent, reclassent et filtrent avant même que le modèle voie les données : un modèle doté d’un meilleur raisonnement et d’un contexte effectif plus vaste peut souvent trouver ce qu’il lui faut dans un dépôt bien organisé, sans toute cette machinerie. Les règles d’affaires codées en dur dans les prompts : un modèle plus intelligent les infère à partir d’un seul exemple. Les portillons de révision humaine à chaque transfert : quand le taux d’erreurs de logique du modèle chute, ces portillons deviennent des goulots d’étranglement plutôt que des filets de sécurité.

L’échafaudage qui était de l’infrastructure devient de la dette technique du jour au lendemain.

Ce que les entreprises devraient bâtir à la place

Les organisations qui pivoteront le plus vite sont celles qui bâtissent autour des résultats plutôt qu’autour des limites. La différence est structurelle.

Des spécifications de résultats, pas des prompts procéduraux. Plutôt que de dire au modèle comment traiter une demande client étape par étape, spécifiez à quoi ressemble une bonne résolution et quelles contraintes elle doit respecter. « Résous le problème de ce client en t’appuyant sur notre base de connaissances et nos politiques. Le client doit repartir satisfait. La résolution doit respecter notre politique de retour. » Comparez cela au classificateur d’intentions à 14 catégories, à l’étape de récupération de cinq articles, au gabarit de réponse. L’un survit à une mise à niveau du modèle. L’autre devient un passif.

Des contraintes et des garde-fous indépendants du modèle. « Ne jamais divulguer les données financières d’un client » est une règle d’affaires qui tient peu importe l’intelligence du modèle. « Toujours classifier l’intention dans l’une de 14 catégories avant de répondre » est un artéfact de processus qui existe parce que le modèle en avait besoin. Apprenez à faire la différence. Gardez les règles d’affaires. Supprimez la compensation de processus.

L’évaluation à la fin, pas des points de contrôle en chemin. Quand les modèles produisent un résultat juste 99 % du temps plutôt que 85 %, les portillons de révision intermédiaires créent plus de friction que de valeur. Bâtissez une évaluation complète en fin de pipeline qui teste tout : exigences fonctionnelles, exigences non fonctionnelles, cas limites. Si ça passe, on livre. Sinon, on renvoie. C’est ainsi qu’on passe à l’échelle sans faire des humains le goulot d’étranglement.

Des outils aux interfaces claires, pas de la logique d’orchestration. Définissez ce que font vos outils. Laissez le modèle décider quand les appeler et dans quel ordre. Le modèle nous dépasse de plus en plus dans le séquencement des appels d’outils. Notre travail est de nous assurer que les outils eux-mêmes sont fiables et bien documentés.

Le problème organisationnel dont personne ne parle

Le pivot technique est la partie facile. Le pivot organisationnel est celui où les entreprises vont trébucher.

La plupart des équipes d’IA sont aujourd’hui structurées autour de la compensation des limites des modèles. Il y a des ingénieurs de prompts qui raffinent des prompts système. Il y a des ingénieurs de pipelines qui bâtissent des architectures de récupération. Il y a des équipes de révision qui évaluent la sortie du modèle à chaque étape. Quand les modèles s’amélioreront assez pour rendre une grande partie de ce travail inutile, ces rôles ne disparaîtront pas. Ils se transformeront. L’ingénieur de prompts devient un spécificateur de résultats. L’ingénieur de pipelines devient un concepteur d’outils. Le réviseur devient un évaluateur du produit final plutôt que des points de contrôle intermédiaires.

Mais cette transformation exige que l’organisation prenne conscience que le sol est en train de bouger. Les équipes récompensées pour bâtir un échafaudage toujours plus complexe doivent entendre, clairement, que la simplification est l’objectif. Que supprimer mille lignes de prompt vaut plus qu’en ajouter cent. Que l’art de travailler avec ces modèles tient de plus en plus à ce que nous laissons de côté.

À Montréal, la communauté de recherche de Mila étudie ces modèles depuis plus longtemps que la plupart. Les travaux d’interprétabilité qui sortent du laboratoire de Bengio ne sont pas abstraits. Ils nous disent, concrètement, ce que ces modèles peuvent et ne peuvent pas faire, et la frontière bouge plus vite que la plupart des feuilles de route d’entreprise ne le prévoient.

La fenêtre

Mythos n’est pas le dernier modèle de sa classe. OpenAI, Google et d’autres livreront des capacités comparables d’ici quelques mois. La question n’est pas de savoir si ce saut s’en vient. C’est de savoir si votre architecture est prête à en profiter, ou s’il faudra d’abord la rebâtir.

Les organisations qui ont investi dans des données propres, des spécifications de résultats claires, des garde-fous indépendants du modèle et une évaluation de bout en bout brancheront un modèle plus intelligent et en verront immédiatement le bénéfice. Les organisations qui ont investi dans la compensation des faiblesses d’un modèle particulier découvriront que leur couche de compensation est désormais ce qui se dresse entre elles et la prochaine génération de capacité.

La fenêtre pour simplifier, c’est maintenant. Pas quand Mythos sera livré. Maintenant. Parce que la simplification prend plus de temps que quiconque ne l’anticipe, et les modèles n’attendent pas.

Si vous suivez Le Guide du voyageur de l’économie en K, voici la leçon qui relie toute la série. Spécification, jugement, décomposition, orchestration, intention, évaluation : chacune de ces compétences prend de la valeur à mesure que les modèles s’améliorent, et chaque pièce d’échafaudage qui s’y substitue en perd.