DevOps avec IA et LLMOps : du pipeline au modèle qui parle

Informatec Digital » Ressources » DevOps avec IA et LLMOps : du pipeline au modèle qui parle

L'avènement de l'IA générative et des grands modèles de langage a radicalement transformé la conception, le déploiement et l'exploitation des logiciels. De bonnes pratiques DevOps ou l'application des méthodes MLOps classiques ne suffisent plus : l'introduction d'un grand modèle de langage nous plonge dans un univers où le modèle parle, raisonne, improvise et se comporte parfois de manière imprévisible.

Dans ce nouvel environnement, les équipes doivent combiner DevOps, IA et LLMOps pour gérer l'intégralité du cycle de vie des applications LLM , de l'expérimentation et l'ingénierie rapide au déploiement, la supervision, la sécurité et l'optimisation des coûts. Cet article clarifie les complexités et vous guide pas à pas dans l'intégration de ChatOps, DevOps, MLOps, GenAIOps et LLMOps au sein d'une organisation moderne.

Du DevOps et du MLOps au LLMOps : pourquoi le modèle n’est plus statique

Pendant des années, les équipes d'ingénierie ont privilégié l'automatisation de la livraison de logiciels et la réduction des frictions entre le développement et l'infrastructure . Cela a mené à la naissance du DevOps : intégration continue, déploiement continu, infrastructure en tant que code, observabilité et une culture collaborative qui a éliminé les transferts interminables entre les départements.

Lorsque les données sont devenues partie intégrante du produit, le MLOps a émergé en réponse au besoin de reproductibilité et de traçabilité des modèles d'apprentissage automatique . Des pratiques telles que le versionnage des ensembles de données, l'orchestration du pipeline d'entraînement, la détection des dérives et l'évaluation continue des modèles prédictifs ont été standardisées.

Le problème est que les LLM remettent en cause nombre de postulats implicites du DevOps et du MLOps . Ce ne sont pas des API statiques ni de simples fonctions renvoyant un nombre déterministe : elles répondent en langage naturel, combinent contexte, instructions, outils et données en temps réel, et peuvent produire deux résultats différents pour une même entrée.

Cela signifie qu'il ne suffit pas de versionner le modèle et ses pondérations ; il est également nécessaire de contrôler les invites, les modèles, les politiques de sécurité sémantique, les restrictions, les outils connectés, le contexte injecté et même les règles métier qui conditionnent le comportement du système.

Qu'est-ce que LLMOps et quel problème résout-il concrètement ?

On peut considérer LLMOps comme le cadre opérationnel permettant le déploiement, la maintenance et la mise à l'échelle sécurisés, contrôlés et durables des applications basées sur LLM . Il s'agit d'un cadre englobant les pratiques DevOps, le MLOps et les nouvelles fonctionnalités spécifiques aux modèles génératifs.

En résumé, LLMOps se concentre moins sur « l’entraînement du modèle parfait » que sur la maîtrise de son comportement en production . Cela inclut la conception et le versionnage des flux de requêtes, la connexion des LLM aux sources de données internes, la surveillance des coûts des jetons et de la latence, ainsi que la gestion des risques sémantiques (hallucinations, fuites d’informations, biais, réponses toxiques, etc.).

Les besoins auxquels répond LLMOps, et que DevOps/MLOps ne peuvent à eux seuls couvrir, englobent des aspects aussi variés que la traçabilité des conversations, l'évaluation automatique de la qualité des réponses et les tests A/B des variantes comportementales . Il ne s'agit pas seulement de précision classique, mais aussi de cohérence, d'alignement avec les objectifs métier et de sécurité.

De plus, les coûts ne se limitent plus à l'entraînement et à l'hébergement des modèles : chaque requête, chaque contexte étendu et chaque appel simultané entraîne une consommation de GPU ou de jetons sur les API commerciales. Sans une couche LLMOps pour rendre ces dépenses visibles et les relier aux équipements, aux services et aux cas d'utilisation, la facture grimpe de façon imprévisible.

ChatOps + LLMOps + DevOps : les opérations deviennent conversationnelles

L'une des tendances les plus marquantes est l'intégration du ChatOps et du LLMOps au sein de la culture DevOps . Au lieu de se limiter aux tableaux de bord, aux scripts et aux pipelines, les équipes commencent à gérer une part importante du système via des canaux de communication tels que Slack, Microsoft Teams ou Discord.

ChatOps propose que les opérations quotidiennes (déploiements, requêtes de journaux, redémarrages, modifications de configuration) soient exécutées par des bots directement dans le canal de communication , de manière transparente pour toute l'équipe. Chaque commande, action et résultat est enregistré dans la conversation.

Lorsqu'un LLM est ajouté à cette approche, une nouvelle couche d'intelligence apparaît : des chatbots qui comprennent le langage naturel, interprètent les intentions et peuvent déclencher des commandes complexes ou analyser des situations sans que l'opérateur ait besoin de se souvenir de chaque script ou indicateur exact.

Parmi les exemples typiques de cette convergence, on peut citer un bot, alimenté par un LLM, qui lit les métriques de Prometheus et les journaux de Loki lorsqu'une personne tape « le service du groupe X est lent » et suggère des actions telles que la mise à l'échelle des réplicas, la restauration d'une version précédente ou le lancement de tests spécifiques, le tout expliqué en langage naturel.

Sur le plan culturel et opérationnel, cela se traduit par des décisions plus rapides, une intervention manuelle réduite dans les tâches répétitives et une expérience plus fluide pour les équipes DevOps , qui peuvent ainsi passer d'une gestion constante des urgences à un travail sur des améliorations stratégiques.

Principes clés du cycle de vie d'un LLM en production

La mise en œuvre d'un programme de maîtrise en droit (LLM) de qualité n'est pas un projet ponctuel ; il s'agit d'un cycle continu où chaque modification peut influencer le fonctionnement du système . Bien que chaque organisation l'adapte à sa propre réalité, on distingue généralement six grandes étapes qui s'auto-renforcent.

La première phase consiste à entraîner ou à adapter le modèle . Cela peut aller de l'utilisation d'un modèle de base tel quel à l'application d'un réglage fin, de techniques comme LoRa ou d'autres techniques d'optimisation avec vos propres données. L'important ici n'est pas seulement la performance, mais aussi la documentation complète : jeux de données, filtres appliqués, hyperparamètres, versions du tokenizer, architectures testées, etc.

Si cette phase est improvisée et non documentée, le modèle naît sans gouvernance . Il sera alors quasiment impossible d'expliquer son comportement ou de reproduire un résultat précis lors d'un audit.

La deuxième étape est le déploiement, où le modèle quitte le laboratoire pour entrer en production. En LLMOps, il ne s'agit pas simplement de « le mettre dans un conteneur » : il faut choisir le matériel , gérer la mémoire pour les contextes de longue durée, définir la topologie du cluster et adapter la capacité en fonction du trafic sans que la latence n'explose ni que les coûts ne deviennent ingérables.

À partir de là, la surveillance continue axée sur le comportement entre en jeu . Il ne suffit pas de se concentrer sur l'utilisation du processeur et de la mémoire vive ; il est nécessaire de surveiller la qualité sémantique des réponses, la stabilité du style, le taux d'erreur, l'évolution du coût par jeton, l'apparition de réponses dangereuses ou incohérentes, ainsi que les variations des temps de réponse selon les différents modèles d'utilisation.

Dans les phases ultérieures, des tâches d'optimisation et de mise au point sont effectuées : ajustement des invites, modification du système RAG, test de variantes du modèle, quantification, réalisation de tests A/B, modification des politiques de sécurité sémantique ou encore perfectionnement des règles métier . Il s'agit d'un processus quasi artisanal, où les équipes données, ingénierie et métier collaborent pour définir les priorités.

Enfin, tout cela s'inscrit dans un cadre de sécurité et de gouvernance multicouche (contrôle d'accès, audit, prévention des fuites, limites d'utilisation, conformité réglementaire) et dans une logique de mise à jour continue, où le modèle et son écosystème sont adaptés aux changements de données, de réglementations et de besoins internes.

GenAIOps et l'approche de flux de notifications dans Azure

Dans l'univers LLMOps, il existe des propositions très spécifiques pour structurer ce cycle de vie. L'une des plus avancées en entreprise est GenAIOps, avec ses flux rapides sur Azure Machine Learning intégré à Azure DevOps , qui offre une approche très systématique pour la création d'applications basées sur LLM.

Le flux d'invite n'est pas seulement un éditeur d'invites ; c'est une plateforme complète pour concevoir, tester, versionner et déployer des flux d'interaction LLM , allant des cas simples (une seule invite) aux orchestrations complexes avec plusieurs nœuds, outils externes, contrôles et évaluations automatisées.

Une fonctionnalité essentielle est le référentiel centralisé des flux de travail , qui fait office de bibliothèque d'entreprise. Au lieu que chaque équipe dispose de ses consignes dans des documents séparés ou dans ses propres référentiels, celles-ci sont regroupées dans un référentiel unique et géré, avec des branches, des révisions et un historique clairs.

De plus, la plateforme ajoute des fonctionnalités d'expérimentation sur les variantes et les hyperparamètres : il est possible de tester différentes combinaisons d'invites, de modèles, de paramètres de température ou de politiques de sécurité sur plusieurs nœuds du flux et de comparer les résultats avec des indicateurs clairs.

En matière de déploiement, GenAIOps avec flux de notifications génère des images Docker qui encapsulent à la fois le flux et la session de processus , prêtes à être exécutées dans des environnements tels qu'Azure App Services, Kubernetes ou les processus gérés. À partir de cette base, des déploiements A/B sont possibles afin de comparer différentes versions de flux en conditions réelles.

Un autre atout réside dans la gestion des relations entre les ensembles de données et les flux. Chaque flux d'évaluation peut fonctionner avec plusieurs ensembles de données standard et de test , ce qui permet de valider les comportements dans différents scénarios avant toute mise à disposition aux utilisateurs finaux.

La plateforme enregistre automatiquement les nouvelles versions des ensembles de données et des flux uniquement en cas de modifications réelles, et génère des rapports complets dans des formats tels que CSV et HTML pour faciliter les décisions fondées sur les données, et non sur l'intuition.

Les quatre phases de GenAIOps avec flux de notification

L'approche GenAIOps décompose le cycle de vie en quatre étapes clairement différenciées, ce qui permet d'éviter le chaos habituel du type « on essaie des choses avec l'IA et on voit ce qui se passe ».

La première phase, l'initialisation, consiste à définir précisément l'objectif métier et à recueillir des exemples de données représentatifs . On y esquisse la structure de base du flux d'instructions et on conçoit l'architecture, qui sera ensuite affinée.

Lors de la phase d'expérimentation, le flux est appliqué à ces données d'exemple, et différentes variations d'invites, de modèles et de configurations sont évaluées . L'itération se poursuit jusqu'à ce qu'une combinaison acceptable soit trouvée, répondant aux exigences minimales de qualité et de cohérence.

Vient ensuite la phase d'évaluation et d'amélioration, où des ensembles de données plus vastes et plus variés sont utilisés pour une analyse comparative rigoureuse . Ce n'est que lorsque le flux démontre des performances constantes, conformes aux normes définies, qu'il est considéré prêt pour l'étape suivante.

Enfin, lors de la phase de mise en œuvre, le flux de travail est optimisé pour une efficacité maximale et déployé en production, incluant des tests A/B, un suivi, le recueil des retours utilisateurs et des cycles d'amélioration continue . Rien n'est jamais vraiment terminé : le flux de travail continue d'être ajusté en fonction des observations d'utilisation réelles.

Cette méthodologie est intégrée dans un modèle de référentiel GenAIOps, avec des pipelines pré-construits axés sur le code et des outils d'exécution locaux et basés sur le cloud pour développer, évaluer et lancer des applications basées sur LLM sans réinventer la roue pour chaque projet.

Intégration avec Azure DevOps : référentiels, pipelines et authentification

Pour que GenAIOps passe de la théorie à la pratique au sein d'une organisation, son intégration avec Azure DevOps est essentielle. Le modèle type repose sur un dépôt Azure Repos comportant deux branches principales, main et development , correspondant à différents environnements et stratégies de déploiement du code.

Le dépôt d'exemple est cloné depuis GitHub, associé à Azure Repos, et le flux de travail habituel consiste à créer des branches de fonctionnalités à partir du répertoire de développement . Les modifications sont ensuite envoyées via des demandes d'extraction, qui déclenchent automatiquement les pipelines de validation et d'expérimentation.

Pour permettre à Azure DevOps d'interagir avec Azure Machine Learning et d'autres services, un principal de service est configuré dans Azure en tant qu'identité technique . Cette identité est utilisée dans une connexion de service Azure DevOps, permettant ainsi aux pipelines de s'authentifier sans exposer de clés en clair.

En règle générale, cette entité dispose des autorisations de propriétaire sur l'abonnement ML ou la ressource de travail, ce qui permet aux pipelines de provisionner des points de terminaison, d'enregistrer des modèles et de mettre à jour les politiques dans les magasins de clés . Pour une sécurité renforcée, son rôle peut être modifié en contributeur en changeant les étapes YAML qui gèrent les autorisations.

De plus, un groupe de variables est créé dans Azure DevOps pour stocker des données sensibles telles que le nom de la connexion au service ou les identificateurs de ressources . Ces variables sont exposées aux pipelines en tant qu'environnement, évitant ainsi d'avoir à intégrer en dur des informations critiques dans le code.

La configuration des dépôts locaux et distants permet de protéger la branche de développement grâce à des politiques de branche exigeant l'exécution d'un pipeline de requêtes d'extraction avant la fusion. Ce pipeline gère les validations de compilation et les flux d'expérimentation, empêchant ainsi l'introduction de modifications erronées.

Une fois le code entré en phase de développement, un pipeline de développement est déclenché qui comprend des phases CI et CD complètes : exécution d’expériences et d’évaluations, enregistrement des flux dans le registre de modèles Azure ML, déploiement des points de terminaison et des tests de fumée, et intégration sur les points de terminaison nouvellement créés.

Le même schéma est reproduit dans une branche de version ou de déploiement, connectée aux environnements de production. Les pipelines CI/CD de production y répètent le cycle d'expérimentation, d'évaluation et de déploiement , mais sur une infrastructure et des données de niveau production, avec un contrôle accru et des revues manuelles supplémentaires si nécessaire.

Une fonctionnalité clé est la « boucle de validation humaine » intégrée à ces pipelines : après la phase d’intégration continue (CI), le déploiement continu (CD) est bloqué jusqu’à ce qu’une personne approuve manuellement la poursuite du déploiement via l’interface Azure Pipelines. Si l’approbation n’est pas obtenue dans un délai spécifié (par exemple, 60 minutes), l’exécution est rejetée.

Mise en œuvre locale et connexion avec les fournisseurs de LLM

Tout ne se déroule pas via des pipelines : GenAIOps prend également en charge l’exécution locale pour des expérimentations rapides . Vous pouvez cloner le dépôt de modèles, créer un fichier .env à la racine et y définir des connexions à Azure OpenAI ou à d’autres points de terminaison compatibles.

Ces connexions incluent des paramètres tels que `api_key`, `api_base`, `api_type` et `api_version`, et sont référencées par leur nom dans les flux (par exemple, une connexion appelée « aoai » avec une version d'API spécifique). Cela permet d'exécuter le même flux localement et dans le cloud sans modification du code.

Pour utiliser cette méthode, il suffit de créer un environnement virtuel ou conda et d'y installer les dépendances nécessaires (promptflow, promptflow-tools, promptflow-sdk, openai, jinja2, python-dotenv, etc.). Vous pourrez ensuite écrire des scripts de test dans un répertoire d'exécution local et lancer des expériences sur les flux définis.

Cette dualité cloud/sur site correspond parfaitement à une approche DevOps mature : les tests à petite échelle sont effectués localement, la validation formelle est réalisée dans des pipelines, puis les déploiements sont effectués dans des environnements plus vastes avec des contrôles et des audits . L’ensemble du code est versionné dans Git et connecté à Azure DevOps.

Outils typiques d'un écosystème DevOps avec IA et LLMOps

Au-delà de la proposition spécifique d'Azure, un écosystème DevOps moderne avec IA et LLMOps s'appuie généralement sur un ensemble d'outils qui couvrent le ChatOps, l'orchestration de modèles, la surveillance et l'observabilité.

Dans la couche ChatOps, il est courant de combiner Slack avec des bots comme Hubot , Microsoft Teams avec des agents basés sur Power Virtual Agents, ou Discord avec des frameworks comme Botpress ou Rasa pour créer des assistants personnalisés qui se connectent aux pipelines, aux systèmes de surveillance et aux services internes.

Dans le domaine LLMOps/MLOps, les plateformes telles que Kubeflow et MLflow sont courantes pour la gestion des pipelines, des enregistrements de modèles et des expériences, en plus d'outils spécifiques tels que Weights & Biases (W&B) pour le suivi avancé des métriques, les comparaisons d'exécutions ou les visualisations approfondies.

Le développement d'applications sur LLM implique généralement l'utilisation de frameworks comme LangChain ou de bibliothèques telles qu'OpenLLM , qui facilitent l'assemblage de chaînes d'invites, de connecteurs vers des données externes, d'outils et d'agents multi-étapes. Parallèlement, des solutions d'observabilité spécifiques à LLM émergent, permettant le suivi des invites, des réponses, des coûts et de la qualité.

En complément des pratiques DevOps classiques, des outils comme Jenkins ou GitLab CI restent pertinents pour la partie CI/CD, Kubernetes et ArgoCD pour le déploiement continu natif du cloud , et des piles d'observabilité comme Prometheus, Grafana et Loki pour les métriques, les tableaux de bord et les journaux.

Défis, limites et adoption progressive

Le déploiement de toutes ces pratiques et outils a un coût. La complexité de la gestion des invites, des versions de modèles et des variantes de flux de travail est considérable, surtout lorsque plusieurs équipes travaillent simultanément — un scénario où des stratégies comme GitOps s’avèrent utiles pour coordonner les modifications et les déploiements.

De plus, les bots ChatOps et les LLM dotés de capacités d'action introduisent des risques de sécurité considérables s'ils disposent d'autorisations excessives dans les environnements de production ou si les surfaces d'exposition des données ne sont pas correctement contrôlées.

À cela s'ajoute la dépendance à l'égard de modèles open source aux licences sensibles ou d'API commerciales susceptibles de modifier les conditions, les prix ou les limites. Qui plus est, l'évaluation rigoureuse des LLM en production demeure un domaine non exploré, et de nombreuses questions restent sans réponse.

Il est donc judicieux d'aborder l'adoption de LLMOps et de ChatOps au sein de DevOps de manière progressive et contrôlée , en commençant par automatiser les tâches répétitives avec des bots simples (redémarrages, requêtes de journalisation, étiquetage des builds, etc.).

Par la suite, les LLM peuvent être introduits pour des tâches de support, la classification des incidents ou l'assistance au débogage , par exemple pour expliquer les erreurs des journaux ou proposer des mesures d'atténuation basées sur la documentation interne.

Une fois l'opération ML classique stabilisée, il est temps d' aborder le LLMOps avec des modèles de langage spécialisés pour des domaines tels que le service client, le DevSecOps ou l'assurance qualité, en tirant parti de tout ce qui a été appris lors des phases précédentes.

L'horizon vers lequel convergent toutes ces pratiques est un environnement d'ingénierie conversationnel, prédictif et de plus en plus autonome , où une grande partie du développement et de l'exploitation s'exprime en langage naturel et où l'IA aide à prendre des décisions proactives concernant les déploiements, la mise à l'échelle ou les restaurations.

Grâce à cette panoplie de solutions (DevOps, ChatOps, MLOps, GenAIOps et LLMOps), les organisations disposent d'un cadre solide pour construire et maintenir des systèmes basés sur le LLM qui apportent une réelle valeur ajoutée , tout en conservant le contrôle sur la qualité, les coûts, la sécurité et l'alignement avec les objectifs de l'entreprise, au lieu de rester au stade de simples prototypes ou de tests isolés qui s'effondrent dès leur mise en production.