Qu’est-ce que le cycle de vie de développement des agents (ADLC) ?

La puissance et la prolifération des agents IA, des systèmes logiciels qui utilisent de grands modèles de langage (LLM) comme moteur de décision pour planifier et exécuter de manière autonome les tâches nécessaires à la réalisation d’un objectif défini, ont accéléré la transformation des workflows en entreprise. Cette transformation a progressé plus vite que la capacité de nombreuses entreprises à adapter leurs structures IT traditionnelles aux exigences propres à l’intégration de l’IA agentique, ce qui a créé un écosystème fragmenté. L’ADLC introduit des spécifications communes et des pratiques partagées afin de favoriser la fiabilité des systèmes agentiques entre différents outils, plateformes, fournisseurs et environnements d’entreprise.

Nombre de processus IT standard actuels ont évolué dans le contexte du développement logiciel traditionnel et reposent sur les hypothèses propres aux systèmes statiques et déterministes. Ces processus sont souvent mal adaptés à la nature dynamique et probabiliste des LLM qui régissent le comportement des agents : on les appelle « agents IA » parce qu’ils disposent littéralement d’une capacité d’action pour déterminer comment exécuter les tâches. Des normes et spécifications communes tenant compte de cette évolution peuvent réduire considérablement les risques associés et accélérer l’adoption responsable de l’IA agentique.

 Pour que l’IA agentique puisse se développer de manière durable et efficace, les agents IA doivent s’intégrer de façon prévisible entre différents modèles, plateformes, fournisseurs et écosystèmes sectoriels. À l’heure actuelle, presque chaque plateforme de création d’agents IA possède son propre format de définition des agents, son propre schéma d’appel aux outils et aux fonctions, son modèle de gestion de la mémoire et de l’état, sa suite de tests, ses protocoles de déploiement et son système de gestion des versions. Cette fragmentation nuit à l’interopérabilité, augmente les coûts de changement et renforce la dépendance aux fournisseurs, ce qu’une étude récente a identifié comme une préoccupation majeure, juste après la sécurité, pour les responsables métier et techniques qui évoluent dans l’écosystème des fournisseurs d’agents IA.¹ Sur le plan opérationnel, cette fragmentation limite également le potentiel de transfert des compétences et des workflows.

Si des normes et pratiques standardisées peuvent atténuer ces inefficacités, les entreprises doivent adopter et faire respecter des protocoles structurels qui s’appuient sur les habitudes et préférences établies des développeurs, au lieu de les contrarier. L’ADLC vise donc à traduire les pratiques émergentes des développeurs en expériences agentiques de référence.

L’ADLC intègre les principes clés du DevSecOps afin d’inscrire le développement des agents IA dans une série de phases interconnectées et largement interdépendantes. L’objectif et les pratiques de chaque phase, ainsi que leurs relations mutuelles, sont abordés plus loin dans cet article. Tous les détails, recommandations et spécifications figurent dans le guide officiel IBM consacré à l’ADLC.

Certaines hypothèses et bonnes pratiques standard du cycle de vie traditionnel du développement logiciel (SDLC) sont mal adaptées à la création d’agents IA. Pour réussir leurs initiatives d’agents IA d’entreprise, les entreprises doivent comprendre et prendre en compte les différences fondamentales entre les logiciels traditionnels et les systèmes agentiques.

• Déterministe ou probabiliste : les logiciels traditionnels reçoivent des instructions explicites et déterministes, sous forme de code impératif, pour atteindre un objectif final seulement implicite ; les agents IA reçoivent un objectif final explicite et des garde-fous comportementaux, puis doivent utiliser des outils, des sources de données et un raisonnement autonome pour déterminer la meilleure manière d’y parvenir. Dans un système agentique, fournir deux fois la même entrée peut produire deux sorties différentes.

• Statique ou adaptatif : les logiciels traditionnels ont des fonctionnalités fixes, et leur comportement ne change que si le code qui le régit est activement modifié. Le comportement d’un agent peut évoluer en fonction des retours de son environnement.

• Piloté par le code ou par les résultats : la nature déterministe et linéaire des logiciels traditionnels permet aux développeurs de prédire la réussite d’un programme à partir de mesures stables et relativement objectives de la qualité du code. La nature probabiliste de l’IA agentique signifie qu’une implémentation optimale peut produire des performances d’agent sous-optimales, tandis que des prompts imparfaits et sous-optimaux peuvent néanmoins générer des résultats exacts. L’évaluation des systèmes agentiques exige donc une mesure systématique des résultats métier et du comportement des agents dans la durée.

Point peut-être le plus crucial, les systèmes agentiques et les logiciels traditionnels présentent des modes de défaillance très différents.

Les logiciels traditionnels échouent à cause d’erreurs logiques ou de cas limites qui « cassent » les instructions rigides de leur code. Ces défaillances sont généralement évidentes : le logiciel plante ou produit des résultats incohérents. Comme les logiciels traditionnels sont déterministes, toute défaillance peut être rattachée à un défaut précis dans le code, qui peut ensuite être débogué.

À l’inverse, les systèmes agentiques échouent généralement à cause d’hallucinations ou de problèmes d’alignement. Les agents IA fonctionnent en interprétant l’intention de manière probabiliste, à partir des prompts système, des garde-fous et du contexte, plutôt qu’en exécutant la logique stricte et fondée sur des règles des logiciels traditionnels. Un agent peut apparemment « résoudre » un problème tout en violant des contraintes ou en fournissant avec assurance un résultat incorrect. Ces défaillances sont plus faciles à manquer : un résultat plausible mais faux est plus difficile à repérer qu’un plantage système. Elles sont aussi plus difficiles à retracer : l’échec global d’un workflow agentique complexe en plusieurs étapes peut provenir du résultat incorrect d’un seul appel probabiliste à un outil, et l’erreur en cause peut ne pas se reproduire lors d’une évaluation ultérieure.

L’ADLC intègre donc l’observabilité, le confinement et l’évaluation continue à chaque phase. Le développement agentique doit trouver un équilibre efficace entre la nécessité de tester rigoureusement les scénarios réels et celle de contenir les risques dans le monde réel.

Le cycle de vie du développement des agents (ADLC) organise le processus de création, de déploiement, d’optimisation et de gestion des agents IA en phases distinctes, dont certaines se combinent pour former des boucles itératives.

• Planification : impliquer toutes les parties prenantes concernées afin d’aligner les cas d’utilisation, les objectifs, les indicateurs de réussite et les résultats métier visés, dans le but d’éclairer le cadre d’évaluation. Définir et documenter en langage naturel le comportement attendu des agents et les procédures opérationnelles standard.

• Codage et création : développer les agents, ce qui implique notamment le choix du modèle, la conception des prompts et l’orchestration. Identifier les services externes pertinents, comme les outils, bases de données et API, puis les intégrer dans une couche d’entreprise à l’aide du model context protocol (MCP). Appliquer une gestion rigoureuse des versions, du sandboxing et des modèles de passerelle.

• Tests et publication : exécuter des évaluations structurées par rapport à des benchmarks prédéfinis, appliquer les contrôles de politiques, réaliser des tests de sécurité et des exercices de red teaming, puis certifier l’inscription des agents dans un catalogue gouverné. Répéter de manière itérative les phases Codage et création, puis Tests et publication, en boucle si nécessaire.

• Déploiement : une fois certifiés, déplacer les agents vers les environnements de production, avec un déploiement progressif par étapes afin de maîtriser les risques. Adopter un modèle de passerelle pour assurer une gouvernance efficace et l’application des politiques. Assurer la gouvernance à l’exécution grâce au sandboxing, à la gestion des versions, aux stratégies de rollback, à l’application des règles de sécurité et à la limitation des performances.

• Exploitation : observer et optimiser en continu les agents déployés, en suivant des métriques en temps réel, comme la précision, la latence, le coût et la satisfaction des utilisateurs, tout en restant attentif à la dérive des modèles ou aux régressions de performance. Utiliser ces boucles de retour pour optimiser les prompts, outils, modèles et politiques de mémoire en matière de performance et de sécurité, en répétant de manière itérative la boucle Déploiement-Exploitation si nécessaire.

• Surveillance : une fois le système entièrement validé et optimisé, poursuivre la surveillance et réaliser des audits continus en matière d’équité, de transparence et de conformité réglementaire. Maintenir un catalogue bien gouverné des agents et des outils afin de faciliter l’observabilité et la reproductibilité.

En respectant ces phases et les priorités qu’elles visent à traiter, chacune étant abordée plus en détail dans les sections suivantes, les entreprises peuvent faire évoluer leurs agents de manière sûre et maîtrisée, en veillant à ce qu’ils restent fiables, auditables et alignés sur la valeur métier.

Le processus de développement des agents commence par l’alignement sur les cas d’utilisation, dont découlent toutes les autres considérations de planification.

Les résultats métier précis que vos agents doivent atteindre détermineront les indicateurs clés de performance (KPI) et autres indicateurs de réussite utilisés pour évaluer leurs performances. L’automatisation du support client peut être évaluée principalement à l’aune de la satisfaction des utilisateurs finaux et de la réduction des coûts, tandis qu’un agent de codage peut être évalué sur la latence et la qualité du code. Le choix de la formulation mathématique précise de ces indicateurs constitue en soi une décision d’architecture critique, car différentes méthodes de calcul peuvent produire des signaux de réussite et des incitations opérationnelles différents.

Des résultats métier précis pilotés par des agents appellent des processus, tâches et sous-tâches spécifiques à automatiser par les agents, et nombre de ces tâches exigeront que les agents IA disposent d’un accès à des outils, jeux de données, bases de connaissances et API spécifiques. Compiler et obtenir la liste de toutes les ressources nécessaires avant la phase de codage et de création est essentiel pour assurer un processus de développement efficace.

Cela dit, la décision la plus importante à prendre lors de la phase de planification est de déterminer s’il faut réellement créer un agent IA.

IBM recommande de rechercher la solution la plus simple capable de répondre à votre besoin métier spécifique. Si un problème peut être résolu avec une automatisation traditionnelle, des systèmes de recherche d’informations ou un prompt bien conçu, l’IA agentique risque d’introduire une complexité inutile. Par exemple, un système qui automatise les réponses aux e-mails clients nécessiterait un agent IA, mais un système de classification des e-mails n’a besoin que d’un LLM et d’un prompt bien conçu.

À condition que les gains de performance que l’IA agentique peut apporter à votre cas d’utilisation par rapport à des solutions plus simples justifient l’augmentation associée des coûts et de la latence, une mise en œuvre idéale de l’IA agentique dans les environnements d’entreprise implique généralement les éléments suivants :

• Périmètre produit bien défini. Priorisez les problèmes métier précis qui exigent du jugement ou un raisonnement en plusieurs étapes, et qui ne peuvent pas être traités correctement par une automatisation générale fondée sur des règles. Les problèmes qui exigent du jugement contextuel, un raisonnement en plusieurs étapes et une prise de décision complexe à grande échelle sont des candidats idéaux pour l’IA agentique.

• Indicateurs de réussite clairs. L’IA agentique fonctionne bien dans les scénarios où la réussite peut être évaluée de manière objective et quantitative, et où des standards peuvent être appliqués. Cela fournit non seulement la justification solide nécessaire du point de vue métier, mais aussi les objectifs d’optimisation indispensables sur le plan opérationnel.

• Complexité maîtrisable. En raison de la nature probabiliste de l’IA agentique, les systèmes multi-agents présentent des risques d’enchaînement, où l’échec d’une seule étape peut avoir des conséquences importantes. Les bénéfices théoriques d’un système agentique doivent clairement l’emporter sur sa complexité opérationnelle.

L’analyse approfondie des déploiements d’IA agentique en entreprise a fait apparaître des cas récurrents qui offrent une valeur régulière avec un niveau de risque maîtrisable : les processus à forte composante documentaire, le support client ou service client, et le travail de connaissance documentable. Ce sont des points de départ idéaux.

Une fois que toutes les parties prenantes concernées se sont accordées sur les objectifs, les exigences, les contraintes et les critères de mesure, les équipes passent à la création concrète des agents IA : mise en œuvre des prompts, stratégies de mémoire, logique d’orchestration et cadres d’évaluation.

Les agents doivent être intégrés aux systèmes d’entreprise, aux API, aux outils externes et aux bases de connaissances. Ces intégrations doivent être conçues en tenant compte de la sécurité et de la télémétrie. Des points d’observabilité, c’est-à-dire des fragments de code qui capturent automatiquement des données et mesures opérationnelles instantanées, doivent être injectés aux étapes clés du workflow afin d’enregistrer les transcriptions des agents, y compris les traces de raisonnement, les appels d’outils et les sorties.

À chaque étape du développement, les équipes doivent appliquer des politiques strictes de gestion des versions, à la fois pour les variantes d’agents individuelles et, le cas échéant, pour la logique d’orchestration qui coordonne leur travail au sein d’un système multi-agents.

Le choix du ou des LLM qui alimenteront vos agents IA est l’une des décisions d’architecture les plus importantes. Utiliser un seul modèle pour chaque tâche et chaque rôle est rarement la configuration optimale en termes de performance ; et même lorsque c’est le cas, ce gain de performance incrémental implique des compromis en matière de coût, de latence, ou des deux.

Les développeurs doivent s’appuyer sur un portefeuille de modèles différents : des modèles de raisonnement de pointe pour la planification complexe, des modèles propres à un domaine, obtenus directement auprès de fournisseurs de modèles ou grâce aux efforts de réglage fin de votre entreprise, pour les tâches spécialisées lorsque cela est pertinent, et des modèles plus petits pour réduire les coûts et la latence sur les tâches plus simples et à fort volume.

Toutes les intégrations, qu’il s’agisse d’intégrer des données d’entreprise, des applications tierces ou des systèmes externes, peuvent être traitées comme des intégrations d’outils activées par des serveurs MCP. Idéalement, la plateforme d’ingénierie agentique que vous choisissez vous permet d’adapter le comportement MCP aux besoins de votre cas d’utilisation spécifique. Utilisez un modèle MCP Gateway pour sécuriser et gouverner toutes ces connexions via vos systèmes backend.

Dans la mesure du possible, privilégiez la reproductibilité et les standards ouverts, comme MCP pour les outils et les ressources, OpenTelemetry pour l’observabilité, et des schémas réutilisables pour les prompts. Vous devez également adopter des modèles cohérents pour le stockage et la recherche, l’accès aux outils et la délégation des tâches.

Pour les systèmes d’entreprise exposés à des risques réels, la sécurité de l’IA agentique doit être intégrée directement à chaque étape du développement selon des principes de sécurité by design, plutôt qu’ajoutée a posteriori.

Chaque agent IA doit recevoir un identifiant distinct afin que chacune de ses actions puisse être enregistrée, auditée et correctement attribuée. Cela permet non seulement de remonter de manière fiable à l’origine des problèmes de sécurité, mais aussi de faciliter la conformité avec des cadres réglementaires qui continuent d’évoluer à mesure que l’adoption de l’IA agentique gagne en maturité.

La mise en bac à sable, ou « sandboxing » et les autres pratiques de confinement sont essentielles pour limiter les risques. L’environnement d’exécution, l’accès réseau et l’accès au système de fichiers d’un agent doivent toujours respecter le principe du moindre privilège. Chaque composant d’un système agentique doit disposer uniquement des autorisations minimales nécessaires pour accomplir les tâches qui lui sont assignées.

Tester les prototypes d’agents pour s’assurer qu’ils sont prêts à être mis en production exige plus que les tests unitaires et l’analyse statique du cycle de vie traditionnel du développement logiciel. Cela suppose aussi une validation comportementale approfondie par rapport à des scénarios réels ou à des simulations haute fidélité. Compte tenu de la nature probabiliste des systèmes agentiques, l’échantillon de scénarios de test doit être suffisamment vaste et varié pour offrir un niveau de confiance raisonnable dans le fait que tous les comportements émergents potentiels des agents ont été observés et évalués.

Les agents IA doivent être testés par rapport à des benchmarks prédéfinis et à des contrôles de politiques qui reflètent et imposent précisément les comportements attendus. Cela peut nécessiter la collecte ou la création de jeux de données de référence indiquant la trajectoire qu’un agent doit suivre pour chaque type d’entrée et de situation. Il convient d’utiliser à la fois des évaluations LLM-as-a-Judge et des revues human-in-the-loop, en combinant l’échelle permise par les premières avec le niveau de confiance apporté par les secondes.

Avant et après le déploiement initial, un pipeline robuste d’intégration continue et de livraison continue (CI/CD) est essentiel pour exécuter les tests et les évaluations à l’échelle nécessaire, automatiser les évaluations, évaluer la fiabilité des outils et appliquer les garde-fous de sécurité. Pendant les tests, un système d’intégration continue (CI) permet de s’assurer que la logique de raisonnement d’un agent ne se rompt pas lorsque les modèles et prompts qui le composent sont mis à jour. Même le remplacement du LLM que vous utilisez déjà par sa dernière version peut avoir des effets imprévisibles dans un environnement dynamique.

L’évaluation continue des agents IA à chaque phase post-build de l’ADLC est essentielle à la réussite d’un système agentique. Les évaluations hors ligne réalisées pendant la création et la CI aident à établir des benchmarks sur le comportement global des agents et les résultats obtenus. Les évaluations in-the-loop sont déclenchées à l’exécution pour guider les décisions individuelles d’un agent ; par exemple, dans une application RAG agentique, votre workflow pourrait imposer le calcul d’un score de pertinence contextuelle afin de déterminer si une source récupérée doit être utilisée pour générer une sortie.

Votre cadre d’évaluation agentique doit comprendre plusieurs types d’indicateurs, notamment :

• Indicateurs de qualité, comme le pourcentage de réussite des tâches, la précision et le taux de réussite des appels d’outils

• Indicateurs de sécurité, comme les violations de politiques ou le taux de fuite de données sensibles

• Indicateurs opérationnels, comme la latence, la consommation de tokens et le coût par tâche

• Indicateurs métier, comme les scores de satisfaction ou le coût par résultat

Le red teaming permet d’identifier de manière proactive les vulnérabilités adversariales et les défaillances potentielles d’alignement. Il simule des conditions hostiles, comme les attaques par injection de prompt et les tentatives de jailbreak, afin de tester les contraintes de sécurité dans des scénarios que les tests comportementaux standard pourraient négliger.

Après avoir été testés, optimisés et validés de manière approfondie, les agents IA sont déployés de façon sécurisée dans les environnements d’entreprise. La phase de déploiement doit être envisagée comme une activation délibérée et stratégiquement progressive, plutôt que comme une action unique comparable à l’appui sur un grand bouton rouge « DÉPLOYER ». L’ADLC garantit la sécurité du système à l’exécution grâce au sandboxing, à la gestion des versions, aux stratégies de rollback et aux mécanismes de sécurité.

Le déploiement de vos agents IA doit s’effectuer progressivement afin de maîtriser les risques. Envisagez différentes stratégies de déploiement, comme les déploiements blue-green, rolling ou canary, afin de déterminer celle qui correspond le mieux à vos profils de trafic d’utilisation.Dans un environnement d’entreprise réel et en production, la stabilité doit rester la priorité : un déploiement soigneusement découpé en étapes vous permet de vérifier la résilience de votre système face à des mises à jour significatives.

La mise en bac à sable, ou « sandboxing » consiste à limiter strictement le périmètre d’action et les capacités des agents et de leurs outils, en les exécutant dans des environnements contraints qui appliquent le principe du moindre privilège pour l’accès au calcul, au stockage, au réseau et aux API système. Même si un agent échoue ou se comporte de manière inappropriée, un sandboxing correctement mis en place réduit la portée et l’ampleur des problèmes potentiels. Il s’agit d’une pratique essentielle dans tout scénario où une mauvaise utilisation des outils, une génération de code ou une transformation de données par un agent pourrait avoir des conséquences sur votre base de code, l’intégrité de vos données, vos clients ou d’autres agents.

Les stratégies courantes de mise en œuvre du sandboxing incluent :

• Virtualisation légère

• Profils de sécurité des conteneurs

• Contrôles réseau, généralement via une MCP Gateway

• Politiques d’accès au système de fichiers

• Application des politiques au niveau de la passerelle

L’ADLC ne s’arrête pas une fois vos agents IA entièrement déployés avec succès. À l’image de la boucle itérative formée par les phases Codage et création, puis Tests et publication, les phases Déploiement et Exploitation doivent être envisagées comme les deux volets d’une boucle de retour continue. Alors que l’objectif final de la boucle initiale Création/Tests est que les agents atteignent le seuil minimal de performance nécessaire aux résultats métier visés, l’objectif de la boucle Déploiement/Exploitation est l’optimisation.

Après le déploiement, une supervision opérationnelle continue est nécessaire pour garantir que les performances de votre agent restent fiables, efficaces et sécurisées dans un environnement réel. Les métriques en temps réel, consolidées et facilement accessibles dans un tableau de bord de reporting unifié, doivent être surveillées activement afin de détecter toute dérive ou régression de performance. Toute régression notable, qu’elle concerne l’efficacité opérationnelle ou les retours des utilisateurs finaux, doit être traitée activement. Toute modification apportée pour résoudre ces nouveaux problèmes doit être testée de manière approfondie et déployée progressivement.

L’observabilité de la pile complète est essentielle pour les systèmes agentiques qui doivent non seulement atteindre des niveaux optimaux de performance, de sécurité et de fiabilité, mais aussi les maintenir dans la durée.

Une fois votre mise en œuvre agentique entièrement validée et optimisée en production, réalisez des audits continus portant sur l’équité, la transparence, les risques de sécurité et la conformité réglementaire, en plus des performances globales.

Les standards sectoriels et les exigences légales continuent d’évoluer, et ne pas s’y adapter activement peut entraîner des conséquences réglementaires, un désavantage concurrentiel, ou les deux. La dérive des modèles est un phénomène inévitable, qu’il est préférable de traiter de manière proactive. Les besoins métier évoluent, et les systèmes agentiques mis en place pour y répondre devront évoluer en conséquence.

Pour répondre aux besoins actuels et futurs, les entreprises doivent gérer un catalogue clairement organisé d’agents et d’outils qui précise :

• La propriété, afin de faciliter la responsabilisation et l’escalade des problèmes

• Les versions, pour une pratique disciplinée de la gestion du changement

• La posture de risque, pour éclairer la prise de décision

• Tous les environnements pertinents, afin de maintenir une supervision opérationnelle exhaustive

• L’auditabilité, afin d’accélérer la collecte de preuves, les évaluations, les approbations et le red teaming