L'ingénierie de la fiabilité
Comment construire des systèmes fiables à partir de composants non fiables, et pourquoi ce n'est pas aussi nouveau qu'on le croit.
L'inconfort
Chaque développeur connaît ce contrat :
Même entrée → même logique → même sortie. À chaque fois.
L'IA brise ce contrat. Le même prompt, le même modèle, la même entrée peuvent produire des résultats différents d'un essai à l'autre. Pour des ingénieurs formés aux systèmes déterministes, ça semble fondamentalement cassé.
La résistance n'est pas purement intellectuelle. Elle est émotionnelle. Les ingénieurs construisent leur identité autour de la qualité de leur production, autour du contrôle sur le comportement du système. Quand un composant produit des résultats inconsistants, ça ne remet pas seulement en question une hypothèse technique. Ça remet en question le sentiment de maîtrise qui donne du sens au travail. Reconnaître cela est la première étape pour avancer.
Ce n'est pas cassé. C'est un type de système différent. Et il exige un type différent d'ingénierie de la fiabilité.
Vous le faites déjà
L'inconfort est réel, mais le problème n'est pas nouveau. Les développeurs travaillent déjà avec des composants non fiables tous les jours :
- Les réseaux tombent. Vous réessayez. Vous ajoutez des timeouts. Vous concevez pour la défaillance partielle.
- Les API tierces changent. Vous versionnez. Vous écrivez des tests de contrat. Vous ajoutez des fallbacks.
- Les conditions de course existent. Vous utilisez des verrous, des files d'attente et l'idempotence.
- Les utilisateurs fournissent des données aberrantes. Vous validez, assainissez et rejetez.
Aucun de ces systèmes n'est déterministe au niveau du composant. Ils sont fiables au niveau du système, parce que vous avez construit la fiabilité autour de parties non fiables.
L'IA suit le même patron. Le modèle est un composant non fiable. Votre travail est de construire un système fiable autour de lui.
Le recadrage
Le logiciel classique demande : Est-ce que ça marche ?
Les systèmes IA demandent : À quelle fréquence est-ce que ça marche ?
Ce n'est pas un standard plus bas. C'est un standard plus honnête. Le logiciel classique échoue aussi : il échoue simplement de façons qu'on a appris à cacher (gestion d'erreurs, réessais, dégradation gracieuse). L'IA rend la non-fiabilité visible au lieu de l'enterrer.
La fiabilité, ce n'est pas « ça donne toujours la même réponse ». La fiabilité, c'est « le système performe de manière consistante à l'intérieur de bornes acceptables ». Les bornes sont les vôtres à définir.
La boîte à outils
Le passage du déterministe au probabiliste exige des pratiques d'ingénierie spécifiques. Aucune n'est exotique : c'est la même discipline que vous appliquez déjà aux systèmes distribués, appliquée à un nouveau type de composant.
L'évaluation remplace les tests unitaires
En logiciel classique, les tests vérifient des sorties exactes. En systèmes IA, on évalue des distributions.
Chaque système IA devrait avoir :
- Un jeu de données d'évaluation qui représente le comportement attendu
- Des exécutions automatisées d'évaluation à chaque changement
- Des vérifications de régression qui détectent la dégradation
Ça joue le même rôle qu'une suite de tests. Sans ça, les systèmes IA se dégradent silencieusement, non pas parce que le code a changé, mais parce que le modèle a changé.
Les garde-fous remplacent la confiance
La sortie d'un LLM ne devrait presque jamais être utilisée directement. Le modèle fournit le raisonnement. Le système fournit la fiabilité.
Les systèmes en production doivent inclure des couches de validation :
- Des sorties structurées ou des schémas qui imposent le format
- Des règles d'affaires déterministes qui supplantent le jugement du modèle quand approprié
- Une validation des sorties qui attrape les hallucinations et les violations de contraintes
- Des boucles de réessai et de réparation pour les défaillances récupérables
- Agent réviseur : un agent évaluateur séparé révise la sortie de l'agent principal (voir ci-dessous)
- Revue humaine graduée par le risque là où le coût de l'erreur est élevé : voir portes de validation graduées par le risque pour la répartition HITL / HOTL / HOOTL
Les garde-fous ne sont pas un aveu que l'IA est mauvaise. C'est l'ingénierie qui rend l'IA utile.
Agent réviseur : la posture par défaut en production
Pour le travail non trivial, associez le générateur avec un agent évaluateur séparé (contexte différent, parfois un modèle différent). Le patron est maintenant la posture par défaut en production pour la revue de code (CodeRabbit, Graphite Diamond, Greptile, GitHub Copilot review) et est adopté dans le service client (revue ton + politique), le traitement de documents et d'autres domaines à tâches discrètes.
Pourquoi c'est important : les humains qui notent rapidement une sortie sont des évaluateurs peu fiables d'une sortie incorrecte présentée avec confiance. Les agents réviseurs, exécutés dans des contextes différents, font émerger ce que les humains fatigués ratent. La recherche PoLL (« Panel of LLM judges ») trouve que des jurys de petits modèles surpassent souvent un seul grand juge (Verga et al., 2024), et à moindre coût.
Structure de coût : un agent réviseur séparé sur chaque artefact double approximativement la dépense d'inférence par tâche. À l'Échelon 5, c'est maintenant considéré comme valant le coup : le calcul coût-par-unité-fusionnée fonctionne parce que la revue humaine à l'échelle, elle, ne fonctionne pas.
Des étapes plus petites remplacent les gros prompts
Les gros prompts qui tentent de tout résoudre sont fragiles. Ils combinent trop de modes de défaillance en un seul appel.
Les systèmes IA fiables décomposent les tâches :
- Classifier l'entrée
- Récupérer le contexte pertinent
- Générer la sortie
- Valider la structure et la qualité
- Réparer si nécessaire
Chaque étape peut être évaluée, surveillée et améliorée indépendamment. Des unités de raisonnement plus petites augmentent la fiabilité pour la même raison que les petites fonctions sont plus fiables que les monolithes.
L'observabilité remplace les suppositions
Les systèmes IA en production doivent exposer :
- Les logs de prompts : ce qui est entré
- Les réponses du modèle : ce qui est sorti
- Les scores d'évaluation : à quel point c'était bon
- Les cas d'échec : ce qui a mal tourné
- Les métriques de coût et de latence : ce que ça coûte
On ne peut pas améliorer ce qu'on ne peut pas voir. Et les systèmes IA échouent de façons invisibles sans instrumentation : la sortie a l'air plausible mais est fausse.
Le versionnage remplace la stabilité
Les modèles IA évoluent continuellement. Une mise à jour de modèle peut changer le comportement de façons qu'aucun changement de code n'expliquerait.
Les pratiques d'ingénierie doivent inclure :
- Le versionnage de modèle : épinglez la version du modèle en production. Mettez à jour délibérément.
- Le versionnage de prompts : traitez les prompts comme du code. Suivez les changements. Révisez les diffs.
- L'évaluation à la mise à jour : exécutez votre suite d'évaluation avant et après chaque changement de modèle, de la même façon que vous exécutez les tests avant de déployer une nouvelle dépendance.
- L'itération rapide : quand quelque chose casse, itérez vite. La correction est habituellement dans le prompt, les garde-fous ou l'évaluation, pas dans le modèle.
Traitez les changements de modèle comme des mises à jour de dépendances. Vous savez déjà comment gérer ça.
Modes de défaillance et récupération à haute maturité
La boîte à outils gère les modes de défaillance connus. À maturité Tier 3 / Échelon 5, trois préoccupations supplémentaires deviennent dominantes : deux nouveaux modes de défaillance (sycophantisme, cas limites subjectifs) et un patron de réponse (recalibrage vs débogage) qui distingue la pratique à haute maturité de la pratique à basse maturité. Aucun n'est attrapé par les tests ou la surveillance ; les ingénieurs doivent les reconnaître.
Sycophantisme : une préoccupation structurelle
Les LLM défendent de façon fiable des positions erronées avec confiance. C'est mesuré dans plusieurs études (Sharma et al., 2023 ; Wen et al., 2024 ; OpenAI sur l'hallucination, 2025). Wen et al. ont trouvé que le RLHF rend les modèles meilleurs à convaincre les humains qu'ils ont raison sans les rendre meilleurs à avoir raison (taux de faux positifs +24 % en questions-réponses, +18 % en programmation).
La littérature est en réel désaccord sur la question de savoir si le sycophantisme est une correction d'entraînement traitable ou un artefact structurel du RLHF.
La posture du cadre : traiter le sycophantisme comme une préoccupation structurelle pour les fins d'ingénierie, indépendamment de la trajectoire d'entraînement.
Intégrez des garde-fous de processus (signal externe, agent réviseur, récupération de vérité-terrain, tests exécutables) dans chaque boucle. Ne faites pas confiance à la confiance du modèle comme signal de justesse.
Si l'entraînement l'améliore plus tard, les garde-fous restent une infrastructure utile. Sinon, les garde-fous sont essentiels.
Cas limites subjectifs
À basse maturité, les cas limites sont techniques : les tests ne les attrapent pas, la surveillance les montre comme des anomalies, le correctif est dans le code. À plus haute maturité, le cas limite dominant change : il est subjectif. Un utilisateur signale que l'IA s'est trompée, mais les tests passent, la surveillance est verte, et l'échec est qualitatif.
Exemples :
- Ingénierie : une PR est techniquement correcte mais l'agent a pris une mauvaise voie d'implémentation ; l'utilisateur remarque « ce n'est pas ce que je voulais dire »
- Service client : un ticket résolu par IA contient des faits corrects mais le ton ne correspond pas à l'état émotionnel du client
- Finance : une transaction est correctement catégorisée par la règle mais la règle elle-même représente mal l'intention métier
- Contenu / marketing : un texte est grammatical et conforme à la spec mais perd la voix de la marque
La récupération est la conversation, pas la rustine. Parlez à l'utilisateur. Comprenez ce qu'il essayait réellement d'accomplir. Mettez à jour la spécification ou le contexte, pas le code.
Ce mode de défaillance est bien documenté mais sous-nommé. Les sources praticiennes y font référence sous différents vocabulaires : le problème des 70 % d'Addy Osmani (les derniers 30 % sont du travail humain), la recherche UX NN/g, le PAIR Guidebook. Le cadre le nomme explicitement parce que la réponse opérationnelle diffère structurellement d'une correction de bogue technique.
Recalibrage vs débogage
Quand l'IA se trompe, deux réponses sont possibles :
Corriger l'artefact (code, réponse, document) que l'agent a produit. Traite la défaillance comme un problème de code.
Reconstruire la compréhension de l'agent via un contexte neuf, une spécification ré-articulée, un brainstorm multi-perspectives. Traite la défaillance comme un problème de spécification ou de contexte.
Ces réponses sont opérationnellement distinctes.
La littérature sur l'auto-correction intrinsèque est unanime : un modèle qui s'est engagé dans une mauvaise direction ne le remarquera pas de façon fiable par lui-même ; la réflexion dans la même fenêtre de contexte après une mauvaise réponse compose l'erreur plutôt que de la corriger (Huang et al., 2023 ; Kamoi et al., 2024). Cemri et al. (Why Do Multi-Agent LLM Systems Fail?, 2025) ont trouvé que 41,8 % des défaillances multi-agents sont des problèmes de spécification ou de conception qui nécessitent une respécification, pas une nouvelle tentative.
Heuristique pratique : si la même spécification produit la même mauvaise sortie sur deux runs neufs, déboguez la spécification, pas l'artefact. La plupart des défaillances non triviales à haute maturité sont des problèmes de recalibrage déguisés en problèmes de débogage.
Voir Lab IA § Protocole d'état bloqué pour le patron opérationnel.
Le changement de rôle
Dans ce modèle, les ingénieurs n'écrivent plus principalement de la logique. Ils conçoivent des systèmes qui supervisent l'intelligence. C'est, structurellement, de la gestion : spécifier une intention à un exécutant imparfait, évaluer le résultat plutôt que contrôler le processus, et itérer sur sa propre communication quand le résultat ne correspond pas à l'intention. Les gestionnaires ont toujours opéré dans un monde probabiliste. Les ingénieurs les rejoignent.
- •Écrire la logique d'affaires
- •Implémenter des algorithmes connus
- •Déboguer ligne par ligne
- •Optimiser les chemins d'exécution
- •Concevoir des prompts et des interfaces d'outils
- •Construire des couches de validation et d'évaluation
- •Concevoir des boucles de correction et de réessai
- •Surveiller la performance au niveau système
Ce n'est pas une rétrogradation. C'est un déplacement vers un niveau d'abstraction supérieur, le même déplacement qui s'est produit quand les ingénieurs sont passés de l'assembleur aux langages de haut niveau, ou du bare metal à l'infrastructure cloud. Chaque transition donnait l'impression de perdre le contrôle. Chacune permettait en réalité de gagner en levier.
Le principe fondamental
On ne programme pas l'intelligence. On conçoit des environnements où l'intelligence performe de manière fiable.
La non-fiabilité n'est pas le problème. C'est la nature du composant. L'ingénierie, c'est ce qui transforme un composant non fiable en système fiable.
Ce n'est pas nouveau. C'est ce que les ingénieurs ont toujours fait.
En lien : la maturité du code traite le problème inverse : non pas comment construire des systèmes fiables à partir de sorties IA non fiables, mais comment donner aux agents IA une base de code assez lisible pour produire un travail fiable. Même incertitude, reflétée.
← Retour à l'accueil · Le Lab IA · Standards d'exécution · Le cadre de référence