Fiabilité en cascade : pourquoi quatre composants à 90 % produisent un système qui échoue une fois sur trois

La mécanique mathématique de la défaillance structurelle

Dans un billet technique publié sur sa plateforme personnelle, l’ingénieur et auteur Alokit détaille un phénomène souvent négligé par les équipes développant des systèmes d’intelligence artificielle. Selon lui, un système typique de production en IA assemblé autour de quatre composants – récupération de contexte, vérification de sortie, routage des retours et mesure – peut afficher une fiabilité globale bien inférieure à celle de chacun de ses éléments pris séparément.

L’exemple est frappant : si chaque composant fonctionne correctement neuf fois sur dix, soit un taux de fiabilité de 90 %, le produit des probabilités (0,90 × 0,90 × 0,90 × 0,90) donne une fiabilité de bout en bout de seulement 65,6 %. En d’autres termes, le système échoue sur plus d’une requête sur trois, non parce qu’un composant particulier est défaillant, mais en raison de l’effet cumulatif des « petits écarts » dans la chaîne. Alokit qualifie ce mécanisme de « problème de multiplication ».

80 %, un seuil trompeur

L’auteur illustre ce constat par l’exemple de l’équipe technique de LinkedIn, qui a développé un agent conversationnel IA pour l’évaluation de compétences. Les prototypes précoces, jugés à environ 80 % de l’expérience souhaitée, donnaient l’impression d’un produit presque abouti. Or, les quatre mois de développement qui ont suivi ont été consacrés non pas à changer de modèle, mais à régler, tester et affiner l’infrastructure entourant le modèle. Chaque gain ultérieur d’un point de pourcentage s’est révélé plus coûteux que le précédent.

Alokit cite Chip Huyen, auteur d’un guide très lu sur le déploiement d’applications fondées sur les grands modèles de langage (LLM), qui documente ce schéma de manière récurrente : « La sous-estimation massive de la difficulté à améliorer le produit, en particulier autour des hallucinations », constitue selon elle la source la plus fréquente de déception après le lancement. Les modes de défaillance qu’elle recense – arbitrage précision-latence, échecs de différenciation des outils, incohérence tonale – relèvent tous de la couche d’exécution et n’auraient pas été résolus par l’adoption d’un modèle plus récent.

Passer de 90 % à 97 % : l’impact sur la fiabilité globale

Si l’on applique le même calcul à une équipe ayant porté chacun des quatre composants à 97 % de fiabilité, le résultat passe à 88,5 % (0,97⁴). Pour Alokit, la différence entre 65 % et 88,5 % ne constitue pas une simple amélioration de performance : elle sépare un système que les utilisateurs apprennent à ne pas truster d’un système sur lequel ils peuvent compter. Les sept points de pourcentage gagnés par composant ne proviennent pas d’un meilleur modèle, mais du « travail sans glamour » consistant à construire un contexte réellement correct, une vérification qui attrape effectivement les erreurs, une boucle de retour qui se referme et une mesure qui suit ce qui fonctionne.

L’enchevêtrement des défaillances

Le problème se complique encore en production lorsque les pannes s’entremêlent. Une défaillance dans la récupération de contexte ne reste pas confinée : le système travaille alors sur des informations erronées avant même que le modèle ne les traite, ce qui fausse la vérification en aval. Si la boucle de retour oriente correctement l’échec vers un examen humain, le réviseur passe son temps à diagnostiquer un problème qui a commencé en amont. La mesure enregistre l’échec, mais l’attribution reste floue : était-ce la récupération, le raisonnement ou la vérification ?

Alokit rejoint ici l’analyse de Chip Huyen sur les « défis spécifiques à l’IA qui ne peuvent être résolus avec davantage de puissance de calcul » : les défaillances ne résident pas dans un composant isolé, mais dans les interactions entre composants. Un système dépourvu d’infrastructure de couche d’exécution ne se contente pas d’échouer plus souvent : il échoue de manière plus difficile à diagnostiquer, parce que la panne se répartit sur une pile que personne n’a conçue pour être observable.

Une question stratégique pour les équipes produit

Alokit oppose deux approches. Après une démonstration convaincante, la plupart des équipes demandent « quelles fonctionnalités ajouter ». Les équipes qui parviennent à livrer en production posent une autre question : « À quoi ressemble l’échec de bout en bout, et le mesurons-nous ? » Ces deux questions produisent des produits différents.

« Le problème de multiplication est la raison pour laquelle la deuxième question importe, écrit Alokit. Si vous ne suivez pas explicitement la fiabilité de bout en bout – non pas les métriques par composant, mais le pourcentage d’interactions utilisateur qui aboutissent du début à la fin – vous ne savez pas si votre système tourne à 65 % ou à 88,5 %. Vous avez des intuitions. Vous avez des métriques par composant. Vous avez des plaintes d’utilisateurs quand les choses cassent suffisamment fort pour remonter. Vous n’avez pas le chiffre. Et vous ne pouvez pas corriger un chiffre que vous ne mesurez pas. »

Ce billet développe les thèmes du chapitre 10 de l’ouvrage d’Alokit, Wrong by Default: What AI Builders Know That Everyone Else Doesn’t, disponible au format Kindle.