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
- Une revue humaine là où le coût de l'erreur est élevé
Les garde-fous ne sont pas un aveu que l'IA est mauvaise. C'est l'ingénierie qui rend l'IA utile.
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.
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.
← Retour à l'accueil · Le Lab IA · Standards d'exécution · Le cadre de référence