Le débat sur la “nerfing” de Claude n’est pas à propos de Claude, mais de ce qui se passe lorsque vos opérations fonctionnent sur les décisions de quelqu’un d’autre.

Au début de cette année, Stella Laurenzo, directrice senior de l’IA chez AMD, a publié des données de télémétrie provenant de près de 7 000 sessions de code Claude, documentant quelque chose que les ingénieurs ressentaient mais avaient du mal à articuler : entre janvier et mars, la profondeur de raisonnement visible a diminué de 73 %, les appels d’API par tâche ont augmenté de quatre-vingts fois, et le modèle lisait beaucoup moins de fichiers avant de faire des modifications. Les chiffres se sont propagés rapidement. L’interprétation s’est propagée encore plus vite.

Anthropic conteste le cadre. L’entreprise affirme que les changements reflètent des décisions de produit délibérées, notamment un nouveau mécanisme de réflexion adaptative et un passage à l’effort moyen par défaut. Des analystes indépendants ont également remis en question certaines parties de la méthodologie. Le débat est en cours, et des personnes raisonnables sont en désaccord sur ce qui s’est réellement passé.

Mais voici la partie qui compte si vous dirigez une entreprise sur le dessus de ces systèmes : que ce soit une dégradation ou un réglage délibéré ne change pas ce que les opérateurs d’entreprise ont vécu. Ils ne pouvaient pas le prédire. Ils ne pouvaient pas le contrôler. Et certains d’entre eux l’ont ressenti en production avant de comprendre ce qui se passait. C’est l’histoire réelle, et elle n’a rien à voir avec Anthropic en particulier.

Ceci est un problème de dépendance, et non un problème de modèle.

Ce que nous décrivons a un nom : la fragilité du modèle. C’est la condition dans laquelle des opérations critiques sont étroitement liées au comportement d’un seul modèle, de sorte que tout changement au niveau du modèle, qu’il s’agisse d’une décision de réglage, d’une nouvelle valeur par défaut, d’un changement de routage basé sur la capacité ou d’une dépréciation silencieuse, affecte directement l’entreprise, sans tampon et sans avertissement.

Ceci n’est pas un nouveau modèle. Le GPT-4 a traversé une version de cela en 2023. Le Claude 3.5 a traversé une version de cela en 2024. Le Claude Opus traverse une version de cela maintenant. Cela se reproduira avec le prochain modèle de pointe, et avec celui d’après. Non pas parce que tout fournisseur agit de mauvaise foi, mais parce que l’optimisation d’un modèle de pointe pour le coût, la latence et l’échelle à volume mondial est exactement ce que les fournisseurs de pointe doivent faire. Leurs incitations et celles d’une entreprise qui exécute des opérations de production sur le dessus sont liées. Ils ne sont pas identiques. Ils ne le seront jamais.

Nous avons lancé Qurrent en 2023 et avons les connaissances historiques pour savoir comment les cycles de logiciels d’entreprise se déroulent : une entreprise investit dans l’IA. La démo fonctionne. Le pilote fonctionne. Ensuite, il passe en production, quelque chose se déplace au niveau du modèle, et soudain le client possède le problème. Ils sont ceux qui maintiennent les flux de travail, qui poursuivent les régressions, qui absorbent la perturbation. Cela n’a jamais eu de sens pour moi comme modèle durable pour les opérations d’entreprise.

La version entreprise de cette histoire est opérationnelle, et non technique.

Pour les développeurs, la situation actuelle est inconveniente. Les budgets de jetons brûlent plus vite. Les sessions de codage sont interrompues. Les benchmarks déçoivent. C’est un problème réel, mais c’est un problème recoverable.

Pour les entreprises qui exécutent des opérations financières, des flux de travail de conformité, des comptes débiteurs et créditeurs, et des processus de back-office complexes, les enjeux sont différents. Ces flux de travail ne peuvent pas absorber une mauvaise semaine. Les erreurs s’accumulent. Le volume s’accumule. Les SLA sont des engagements envers des clients réels, et non des préférences internes. Le moment où un modèle commence à sous-performer sur un processus à haute mise est celui où les dégâts s’accumulent, que quelqu’un ait remarqué ou non.

Ce qui rend les choses plus difficiles, c’est que la plupart des entreprises qui ont essayé de devancer l’IA en construisant des agents internes sur un seul modèle découvrent maintenant à quel point cette fondation était incomplète. Le premier agent était la partie facile. Ce qui n’a pas été construit, c’est l’infrastructure environnante : des cadres d’évaluation qui détectent la dérive comportementale avant qu’elle n’atteigne un client, une logique de basculement qui redirige le travail automatiquement lorsque le modèle commence à sous-performer, et une gouvernance continue capable de suivre un paysage qui change tous les trimestres. Ces trois lacunes ne restent pas gérables. Elles grandissent en une fonction d’ingénierie permanente que personne n’a budgétisé, composée de personnes dont le travail est essentiellement de suivre les décisions prises par des fournisseurs sur lesquels ils n’ont aucune influence.

Ceci est à quoi ressemble réellement la résilience en production.

Chez Qurrent, nous avons construit la main-d’œuvre numérique pour être agnostique par rapport au modèle dès le départ, non comme une position marketing, mais comme une exigence architecturale. Chaque tâche est acheminée vers le modèle qui fonctionne le mieux pour cette tâche, évalué en continu. Lorsqu’un meilleur modèle est livré, les clients l’obtiennent automatiquement. Lorsqu’un modèle actuel régresse sur un flux de travail spécifique, la couche d’orchestration redirige ce travail en quelques secondes, sans intervention humaine et sans que personne ne se réveille à 2 heures du matin pour un fil de discussion Slack.

En dessous, des simulations automatisées sont exécutées contre les flux de travail de production 24 heures sur 24, mesurant si les sorties correspondent au comportement attendu. La dérive est détectée au niveau de l’infrastructure, avant que l’équipe d’exploitation ne la ressente et longtemps avant qu’un client ne la ressente. Et chaque décision prise par chaque travailleur numérique est enregistrée et consultable, une véritable boîte de verre, car vous ne pouvez pas gouverner ce que vous ne pouvez pas voir.

Ces fonctionnalités ne sont pas des fonctionnalités premium. Elles sont le prix d’entrée pour exécuter l’IA en production à l’échelle de l’entreprise. La plupart des entreprises apprennent cela au milieu d’un cycle d’actualités, ce qui est la façon coûteuse de le découvrir.

La question qui vaut la peine d’être posée ce trimestre.

Si le modèle sur lequel vos opérations dépendent le plus avait une mauvaise semaine le trimestre prochain, combien de vos flux de travail en ressentiraient les effets ? Comment le sauriez-vous ? Et combien de temps faudrait-il pour contourner le problème ?

Si la réponse à la deuxième question est “nous entendrions parler d’un client”, l’opération n’est pas prête pour la production. C’est un pilote qui fonctionne à l’échelle, et la distinction est plus importante que la plupart des dirigeants le réalisent jusqu’à ce que ce ne soit plus le cas.

Le débat actuel est, d’une manière détournée, utile. Chaque CFO et COO qui regarde cela se dérouler vient de se procurer une prévisualisation gratuite de ce à quoi ressemble la fragilité du modèle sous une charge opérationnelle réelle, sans avoir à la payer lui-même. La bonne réponse n’est pas de basculer de modèle. C’est de construire des opérations qui ne dépendent pas d’un seul modèle.

La technologie continuera à évoluer. C’est la seule certitude sur ce marché. Les entreprises qui sortiront de cette décennie les plus fortes ne seront pas celles qui ont choisi le bon modèle. Ce seront celles dont les opérations n’ont jamais eu à s’en soucier.