Les applications d’IA générative bouleversent les principes, les mentalités et les compétences de longue date en matière d’ingénierie de la fiabilité. Voici comment les experts font face à cette perturbation.
Les ingénieurs chargés de veiller au bon fonctionnement des systèmes mondiaux sont confrontés à une courbe d’apprentissage abrupte – et à certains égards sans précédent –, à mesure que l’IA générative prend une place centrale dans l’informatique.
Ce fut le sujet de discussion dominant de la SREcon Americas 2025 cette semaine. De la session générale de lancement par un vice-président d’entreprise de Microsoft sur les leçons tirées de la construction de Microsoft Azure Copilot jusqu’aux sessions de type « bird-of-a-feather » (session informelle) et aux discussions de couloir sur les opérations de grands modèles de langage (LLMOps).
L’IA générative crée un changement profond dans la façon dont les systèmes se comportent et, par conséquent, un changement profond dans la façon dont ils doivent être gérés, déclare Niall Murphy, cofondateur et PDG du fournisseur d’outils SRE Stanza Systems. Niall Murphy est plus connu dans l’industrie comme l’un des coauteurs du livre fondateur de Google « Site Reliability Engineering » en 2016.
Avec le LLMOps, « nous entrons dans un monde où le déterminisme en ce qui concerne la gestion d’un système a disparu, et nous sommes dans une gestion probabiliste », avance M. Murphy lors d’une interview avec Informa TechTarget. « Ainsi, un grand nombre de techniques, de mentalités et d’approches issues de la cybernétique des années 1950 doivent être remplacées par des éléments, tels que les signaux de confiance et les approches qui tentent de prendre en compte la globalité d’un système plutôt qu’une réponse spécifique ».
Microsoft Azure Copilot : les leçons apprises
Brendan Burns, vice-président de Microsoft, a partagé certaines des premières expériences de son entreprise en matière de gestion probabiliste lors du déploiement de Microsoft Azure Copilot au cours d’une présentation en session plénière mardi.
Parmi les problèmes qui ont surgi pour l’équipe qui a construit Azure Copilot, il y a eu un changement majeur dans les systèmes de test, de débogage et d’observation, signale-t-il.
« Il est évident que nous allons surveiller les mêmes choses : renvoyons-nous les résultats avec succès ? Quelle est la latence ? Rien de tout cela ne change, mais cela ne veut plus dire que votre système fonctionne correctement », souligne Brendan Burns. « Et ce qui va nous dire si votre système fonctionne bien, c’est le retour d’information de l’utilisateur ».
Cela signifie que le signal le plus important pour les équipes SRE et DevOps qui gèrent une application basée sur le LLM est le « pouce en l’air » ou le « pouce en bas » de l’utilisateur. Ces avis peuvent être quantifiés avec des mesures statistiques telles que le net promoter score et la satisfaction nette. En fin de compte, « l’on se rapproche davantage de la collecte d’opinion sur les réseaux sociaux que d’un dispositif de mesure précise », compare Brendan Burns.
Mesurer le comportement humain est pour le moins délicat. Par exemple, l’équipe Azure Copilot a remarqué qu’une panne à n’importe quel endroit du système Azure avait tendance à fausser négativement les évaluations humaines des copilotes.
« Dans ces systèmes, le prompt – et en fait, il s’agit plutôt du métaprompt, de ce que vous mettez autour du prompt – est le code. »
Brendan BurnsVice-président, Microsoft
« Si Azure subit une panne générale… le net promoter score des outils clients chute simplement parce que les gens sont un peu grincheux », déclare-t-il. « Ce n’est pas si différent de comprendre si cette panne est due à une défaillance de mon système ou d’une dépendance en aval, mais c’est beaucoup plus flou ».
Le prompt engineering a introduit un nouveau problème pour l’équipe Azure Copilot, poursuit M.Burns. « Dans ces systèmes, le prompt – et en fait, il s’agit plutôt du métaprompt, de ce que vous mettez autour du prompt – est le code », explique-t-il. « Ainsi, les mêmes choses auxquelles vous pensez lorsque vous déployez un logiciel, vous devez y penser lorsque vous déployez le prompt. Tout changement à ce niveau peut avoir un impact très important sur la qualité globale du système que vous êtes en train de construire ».
Les applications LLM sont encore en cours de maturation, notamment en ce qui concerne les approches structurées de versionnement et de développement de méta-prompts, selon Brendan Burns.
« Aujourd’hui, nos environnements de développement intégrés (IDE) ne sont pas vraiment conçus pour gérer ces aspects ou permettre un versionnement indépendant », précise-t-il. « Le fait que ces éléments soient directement intégrés au code pose problème, car il serait préférable de pouvoir les faire évoluer séparément. Nous sommes encore en train d’explorer les meilleures approches pour le développement logiciel dans ce domaine. »
Des LLM pour évaluer des LLM
La manière de qualifier les releases est un autre défi rencontré par l’équipe d’Azure Copilot.
« Auparavant, vous exécutiez tous les tests et si les feux étaient au vert, vous déployiez la solution », relate-t-il. « Avec les prompts et l’IA, chaque changement que vous faites va améliorer certains aspects, mais aussi en dégrader d’autres. Il faut alors arriver à un point où en moyenne vous considérez que c’est meilleur ».
L’équipe Azure Copilot utilise les LLM pour générer des dizaines de milliers de tests et évaluer la qualité des résultats
Une pratique qui a suscité des débats lors de la conférence en matière de confiance.
Un participant a demandé à Brendan Burns : « comment éviter que le modèle triche et valide le résultat alors qu’il n’est pas bon, ou comment éviter de générer uniquement les tests dont ils connaissent la réponse ? »
Brendan Burns a répondu que les modèles ne sont pas conçus pour générer des tests qu’ils savent mauvais.
D’où la nécessité de la multiplication des tests, mais aussi de l’évaluation humaine et des déploiements progressifs.
« Si vous n’avez pas un moyen automatique d’évaluer finement les performances des modèles, alors c’est très difficile de lancer quoi que ce soit. »
Niall MurphyCofondateur et PDG du fournisseur d’outils SRE Stanza Systems
« Si vous n’avez pas un moyen automatique d’évaluer finement les performances des modèles, alors c’est très difficile de lancer quoique ce soit », affirme Niall Murphy.
Et pour la plupart des entreprises, les incitations économiques pour lancer des applications LLM remplacent de nombreuses autres préoccupations.
Les entreprises qui ne disposent pas d’une audience intégrée de 100 000 employés internes pour effectuer des tests canari (comme le fait Azure) peuvent définir des ensembles de tests de qualité des résultats à passer impérativement. Et elles peuvent mesurer des signaux tels que le fait que les utilisateurs posent à un modèle des reformulations de mêmes questions, selon Niall Murphy.
Jacob Scott, un participant à la conférence SREcon et ingénieur logiciel ayant 15 ans d’expérience dans l’excellence opérationnelle, affirme que les évaluations des résultats des modèles peuvent encore être systématisées de certaines manières.
« Il y a des choses que l’on peut faire, comme des sondes ou des tests de chemin d’or [tests très bien définis, “golden path tests” en anglais, N.D.R.] », insiste-t-il. « Vous pouvez effectuer un test de bout en bout avec un trafic synthétique [avec un] ensemble connu d’entrées et de sorties ».
Jacob Scott et d’autres personnes lors de la SREcon ont cité des articles de blog sur les bonnes pratiques LLMOps qui détaillent une telle approche par Hamel Husain, un ingénieur en machine learning qui travaille maintenant comme consultant indépendant, mais qui a auparavant œuvré pour Airbnb et GitHub.
Selon M. Murphy, un autre outil émergent qui pourrait aider les ingénieurs en fiabilité à améliorer les performances du LLM est le protocole de contexte de modèle (MCP), une norme ouverte développée par Anthropic.
« C’est une manière de créer essentiellement une enveloppe lisible par un LLM autour d’un jeu de données ou d’un système, de sorte que le modèle puisse interagir avec lui plus facilement et de manière plus fiable, plutôt qu’avec l’API ou tout autre mécanisme par défaut », explique Niall Murphy. « Les [incitations] à améliorer les tests et la précision [sont plus fortes] pour les entreprises qui construisent des modèles de fondation, que pour l’ensemble dispersé de personnes qui enveloppent leurs solutions avec MCP. Mais elles ne sont peut-être pas totalement absentes [ailleurs]. »
Pour approfondir sur IA appliquée, GenAI, IA infusée
