ADLC : Le nouveau cycle de vie du codage par IA avec Claude Code

AAI LABS
컴퓨터/소프트웨어경영/리더십AI/미래기술

Transcript

00:00:00Vous avez probablement entendu à maintes reprises que le développement logiciel a changé,
00:00:03mais le simple fait d'adopter de nouveaux outils n'a fait qu'effleurer la surface,
00:00:06car les systèmes construits aujourd'hui ne se comportent pas comme les anciens logiciels.
00:00:10Par conséquent, les frameworks sur lesquels les entreprises s'appuyaient ont dû évoluer,
00:00:14car si vous continuez à bâtir sur l'ancien processus, vous ferez face à des problèmes insolubles.
00:00:18Ainsi, pour s'adapter à ce paysage en mutation,
00:00:21un nouveau framework a émergé dans la communauté des développeurs, pensé pour les agents.
00:00:25Et d'ici la fin de cette vidéo, nous allons vous présenter ce nouveau cycle de vie
00:00:29et vous expliquer pourquoi vous devez l'adopter.
00:00:31Pendant de nombreuses années, le développement logiciel a suivi le SDLC.
00:00:35Le cycle de vie du développement logiciel est un processus structuré utilisé depuis des décennies,
00:00:39comprenant des étapes comme la conception, le développement, les tests, le déploiement, la maintenance et le support.
00:00:45L'idée principale est que le logiciel doit être développé en gardant à l'esprit les objectifs commerciaux et les exigences des utilisateurs,
00:00:51le résultat de chaque phase devenant l'élément d'entrée de la suivante.
00:00:54Mais cela n'a fonctionné que jusqu'à ce que l'IA entre dans l'espace technologique.
00:00:57Dès que l'IA a commencé à gagner du terrain, la première chose qu'elle a remplacée fut le codage.
00:01:02Avant l'IA, le développement consistait à écrire du code de manière répétitive,
00:01:06en fusionnant souvent des extraits et de la logique venus d'ailleurs pour bâtir un système résolvant un problème.
00:01:12À mesure que les modèles s'amélioraient et que des outils comme Claude Code et Cursor dominaient l'industrie,
00:01:18le SDLC seul est devenu insuffisant.
00:01:20Il ne peut plus se suffire à lui-même et doit évoluer pour apporter une vraie valeur.
00:01:24C'est pourquoi le cycle de vie du développement agentique, ou ADLC, a été créé.
00:01:28Il comble le fossé entre le SDLC et le paysage technologique actuel.
00:01:32L'ADLC est devenu nécessaire car, dans les systèmes basés sur le SDLC,
00:01:36on connaissait déjà le comportement du système lors de la planification, et on pouvait le vérifier.
00:01:41Pour faire simple, le SDLC traite le logiciel comme un élément statique, tandis que l'ADLC le traite comme un système vivant.
00:01:47Étant donné que les agents IA sont imprévisibles, et que ce sont eux qui évoluent en raisonnant et en adaptant leurs tâches
00:01:53à leur environnement, il devient difficile de les évaluer avec les indicateurs du logiciel traditionnel.
00:01:59La raison principale pour laquelle l'ADLC a été conçu est le non-déterminisme d'un agent IA en production.
00:02:05Avec les agents IA, l'apprentissage et le développement sont continus,
00:02:09et vous ne pouvez pas déterminer à l'avance ce que sera le résultat de l'agent.
00:02:12Lorsque vous travaillez avec l'IA, vos décisions dépendent du prompt, du contexte, des modèles
00:02:16et de tous les outils externes qui y sont connectés.
00:02:18Les modèles en eux-mêmes restent imprévisibles, on ne peut donc pas déterminer ce qu'un prompt retournera avec une précision de 100 %.
00:02:25De ce fait, vous avez des critères de réussite fondamentalement différents de ceux du SDLC.
00:02:29L'ADLC comprend 7 phases, et chaque phase correspond d'une manière ou d'une autre à une phase précise du SDLC.
00:02:36Que vous travailliez sur un système agentique ou non, la première étape reste toujours la planification.
00:02:41Ce qui change, c'est la façon de procéder.
00:02:43Pour les agents, vous ne pouvez pas planifier comme vous le feriez pour des systèmes non agentiques,
00:02:46car contrairement aux systèmes traditionnels, le flux logique ne s'applique pas de la même manière.
00:02:51La première phase de l'ADLC, la préparation et l'hypothèse,
00:02:54vise à acquérir une compréhension concrète du problème avant de s'engager dans la conception d'un système ou d'un modèle.
00:02:59Quand il s'agit d'agents, vous devez comprendre comment les utilisateurs vont interagir avec le système
00:03:04et collaborer avec toutes les parties prenantes pour identifier là où le flux de travail bloque
00:03:07et à quoi ressemblent les efforts manuels répétitifs, car c'est précisément ce que l'agent va résoudre.
00:03:12Ensuite, vous passez en revue les flux de travail et les politiques existantes pour voir comment les choses sont gérées,
00:03:16et une fois cela clair, vous formulez des hypothèses testables sur les aspects où les agents vont aider ou automatiser le flux.
00:03:22Si nous sautions complètement cette phase, nous finirions par automatiser les mauvaises tâches,
00:03:26et au lieu de régler le problème, cela pourrait aggraver les choses.
00:03:28La différence par rapport au SDLC ici réside dans le comportement.
00:03:31Dans le SDLC, le comportement était prévisible car une même entrée donnait toujours le même résultat.
00:03:37Mais l'ADLC est probabiliste en raison de l'implication du modèle,
00:03:40et les mêmes entrées peuvent ne jamais mener exactement au même résultat.
00:03:43Fort de cette connaissance, la première chose à faire est d'activer le mode planification
00:03:47et de demander à l'agent que vous utilisez de planifier le comportement de l'agent que vous développez, et non son implémentation.
00:03:52Demandez-lui de ne pas penser au code mais plutôt de cartographier l'ensemble du flux de travail,
00:03:56la façon dont les agents interagissent avec les utilisateurs, ce qui pourrait mal tourner, les surcharges potentielles,
00:04:00et toutes les autres suppositions concernant le système.
00:04:03De cette façon, le processus de création de votre agent commence par les hypothèses de base,
00:04:06qui s'avèrent être un meilleur guide que de sauter directement dans la planification de l'architecture.
00:04:10Une fois la planification initiale terminée, il y a une autre étape juste après,
00:04:13où vous devez identifier correctement le périmètre et le problème.
00:04:16Cela correspond en fait à la phase d'analyse ou à l'étude de faisabilité du SDLC,
00:04:20où vous analysiez les exigences métiers et déterminiez si l'implémentation était réalisable.
00:04:25Cette phase de l'ADLC consiste donc à identifier les processus clés et le rôle de l'IA pour les résoudre,
00:04:31en définissant les contraintes et les limites techniques,
00:04:33et en établissant d'emblée des KPI clairs, tant commerciaux que techniques, comme le temps, le coût, la latence et la faisabilité.
00:04:39C'est aussi à ce moment que vous définissez les compromis, en sachant quels facteurs sont acceptables et lesquels ne le sont pas.
00:04:44Mais la partie la plus importante de cette phase consiste à cartographier correctement le modèle de responsabilité homme-agent,
00:04:49car cela crée une structure de responsabilisation.
00:04:52Un humain doit toujours effectuer une révision, car on ne peut pas confier toutes les décisions à un agent.
00:04:56À la fin de cette phase, vous disposez d'une documentation adéquate où les étapes du flux sont explicitement définies avec des KPI clés,
00:05:02et où le modèle de responsabilité homme-agent est clairement exposé.
00:05:05C'est important car en cas de défaillance, vous ne pouvez pas rejeter entièrement la faute sur le modèle.
00:05:09La responsabilité finale doit impérativement incomber aux humains.
00:05:12Cette planification de la responsabilité humaine n'était pas requise auparavant, car aucune IA n'était impliquée.
00:05:17Elle définit les limites d'autonomie de l'agent, et si vous sautez cette étape,
00:05:21vous risquez de compromettre votre conformité et votre responsabilité en production.
00:05:24Pour faire cela avec des agents, vous utilisez à nouveau le mode planification, en lui demandant de prévoir les flux, la latence, les problèmes système,
00:05:30toutes les fonctionnalités requises dans l'architecture, et ce à quoi pourrait ressembler un échec.
00:05:34Une fois ces éléments clairement énoncés, l'agent comprend le bon périmètre vers lequel itérer pendant la construction.
00:05:39Une fois le périmètre et les fonctionnalités de haut niveau définis, il est temps de passer à la phase de conception.
00:05:43À ce stade, nous définissons l'architecture système pour l'agent lui-même.
00:05:47Ici, vous décidez du modèle que l'agent va suivre, comme ReAct, Plan-and-Act, une configuration multi-agent, ou toute autre approche.
00:05:54Ensuite, vous planifiez le flux de données d'un point à un autre, ce qui devient d'autant plus crucial avec l'intervention de plusieurs agents.
00:06:00L'agent doit recevoir les données correctes, faute de quoi il créera des problèmes au lieu de vous aider.
00:06:05Vous planifiez également les structures de coûts, comme l'économie des tokens, les fonctions de gestion du contexte, la compaction,
00:06:10et vous évaluez ce que sera le coût du déploiement de cet agent en production,
00:06:14ainsi que ce qui se passera lorsqu'il commencera à gérer plusieurs utilisateurs.
00:06:17C'est également ici que vous choisissez concrètement les modèles à utiliser, le framework d'orchestration,
00:06:23la base de données et toutes les autres technologies impliquées, et c'est là que vous définissez ce que sera le succès
00:06:28avant même d'écrire la moindre ligne de code, afin de pouvoir construire l'agent avec le TDD.
00:06:32Avant que votre système ne devienne actif, vous avez déjà pris en compte les compromis en termes de latence, de précision, d'hallucinations et autres problèmes similaires.
00:06:38Cette phase nécessite également le mode planification de votre agent.
00:06:41Vous lui donnez des prompts pour concevoir un plan global couvrant l'architecture de l'agent, le flux de données, le modèle de coût
00:06:46et la structure technique générale, de manière à passer à l'étape suivante avec un plan concret.
00:06:51Une fois les plans initiaux établis, l'étape suivante est la simulation et la preuve de valeur.
00:06:55Ici, vous utilisez des données réelles pour tester les hypothèses formulées lors des étapes précédentes.
00:06:59Vous créez des prototypes pour déterminer s'il est pertinent de poursuivre le développement de cet agent.
00:07:04En clair, c'est là que vous décidez s'il faut développer l'agent ou non, car à ce stade, le coût d'un échec est beaucoup plus bas.
00:07:10Les activités principales consistent donc à préparer le jeu de données ou la vérité terrain pour les tests de comportement,
00:07:15à bâtir des prototypes pour tester les hypothèses à haut risque documentées précédemment,
00:07:19et à valider la qualité des données, le taux d'hallucination, la précision, la qualité des réponses et les benchmarks.
00:07:25Vous réévaluez également l'hypothèse de départ pour déterminer si elle offrira un retour sur investissement.
00:07:30Les livrables sont des références de performance et de coût correctement mesurées,
00:07:33ainsi que le document de vérité terrain mentionné plus tôt, qui sert d'actif de test pour les tests de régression et le réglage fin du modèle.
00:07:40Cette phase fait office de barrière de validation.
00:07:42Si vos résultats permettent de passer à l'étape suivante, vous pouvez continuer à travailler sur l'agent.
00:07:46Sinon, le projet est un échec, et il vaut bien mieux le découvrir tôt,
00:07:50car si cette solution arrivait en production, les dommages seraient bien pires.
00:07:54Pour ce faire, vous demandez à votre agent IA de créer le premier prototype afin de le tester par rapport à toute la planification effectuée.
00:08:00Mais avant de poursuivre, un mot de notre sponsor, Softr.
00:08:04Les outils de “vibe coding” sont parfaits pour générer une interface, mais dès que vous avez besoin d'une vraie authentification,
00:08:08de rôles utilisateurs, de permissions ou d'une base de données vraiment évolutive, tout s'effondre et vous devez vous remettre à coder.
00:08:14Softr est un générateur d'applications IA qui gère tout cela en un seul prompt.
00:08:18Vous décrivez vos besoins en langage naturel, et le co-constructeur IA génère l'intégralité du stack, la base de données, les pages, la navigation, la connexion et les permissions basées sur les rôles, tout à la fois.
00:08:28Ce ne sont pas de simples pages de démonstration, elles sont pleinement fonctionnelles.
00:08:30Vous pouvez prévisualiser l'application, vérifier ce que voit chaque rôle utilisateur et, dès que vous publiez, votre application est en ligne avec hébergement, groupes d'utilisateurs, sécurité d'entreprise et contrôle d'accès verrouillés.
00:08:40Et vous n'avez pas besoin d'un développeur pour assurer la maintenance.
00:08:42Tout est visuel, ce qui vous permet de mettre à jour les flux, de gérer les utilisateurs et d'ajouter des fonctionnalités vous-même.
00:08:47Le coût réel d'un logiciel ne réside pas dans sa création, mais dans sa maintenance, et c'est ce que résout Softr.
00:08:52Obtenez vos crédits IA gratuits en cliquant sur le lien dans la description et commencez dès maintenant.
00:08:57Cela marque la fin de la phase de planification et nous amène à la partie vers laquelle beaucoup de gens se précipitent : l'implémentation.
00:09:03Les étapes précédentes sont cruciales car si vous les avez bien menées, vous éviterez les problèmes que la plupart des gens rencontrent ici en les négligeant.
00:09:11C'est donc le moment où vous développez concrètement votre agent, construisez la logique centrale et orchestrez votre flux de développement.
00:09:16Et c'est ici que l'on constate l'une des ruptures les plus nettes entre le SDLC et l'ADLC.
00:09:20Dans le SDLC, la logique réside dans le code, la configuration et les dépendances tierces.
00:09:25Dans l'ADLC, cette logique se répartit entre le code, les prompts, les modèles, les outils et les services externes.
00:09:30Vous ne gérez donc plus seulement un logiciel, vous gérez toutes ces couches ensemble, et n'importe laquelle d'entre elles peut modifier le comportement du système.
00:09:38Si vous devez développer des systèmes multi-agents, la nouvelle vue “agents” de Claude Code est un excellent moyen d'orchestrer vos flux de travail.
00:09:44Grâce à la vue des agents, vous pouvez déléguer les tâches bien mieux qu'avec une utilisation standard de Claude.
00:09:49Car au lieu de gérer différentes sessions de Claude Code, vous pilotez une couche d'orchestration unique et donnez des prompts au gestionnaire d'agents pour tout coordonner.
00:09:57C'est également à ce stade que vous intégrez des outils comme les MCP et les API.
00:10:01Par exemple, si vous créez un assistant personnel, vous savez qu'il aura besoin d'un MCP Google Calendar, d'un MCP Gmail et peut-être d'un MCP Notion.
00:10:09Et l'élément le plus important ici est la gestion du contexte.
00:10:11Car dès que vous créez un agent destiné à la production, cela devient l'un des aspects les plus critiques.
00:10:16Même les fenêtres de contexte les plus larges actuellement disponibles, comme celles d'un million de tokens dans Gemini et Opus, requièrent une manipulation prudente.
00:10:24Vous devez veiller à ce que l'agent conserve la bonne mémoire et éviter la dégradation du contexte.
00:10:28Car s'il se retrouve avec trop d'informations non pertinentes, son attention s'éparpille et les résultats se détériorent.
00:10:34À cette étape, vous devez également effectuer des tests du côté développeur pour garantir la cohérence comportementale après chaque modification en validant manuellement l'agent par rapport aux exigences.
00:10:44Le développement et la validation ne sont pas séparés dans les systèmes agentiques.
00:10:48Vous ne pouvez pas avancer sans des tests constants, car même un changement mineur peut avoir un effet massif sur l'ensemble du flux.
00:10:54Vous avez donc besoin d'une validation au niveau développeur tout au long de la création de votre agent, plutôt que de vous fier uniquement à une étape de test ultérieure.
00:11:01Une fois la construction de votre système terminée, la phase suivante est celle des tests.
00:11:05Comme mentionné plus tôt, les tests doivent être continus pendant le processus de création, mais une fois le système bâti, vous le testez dans des conditions proches de la production plutôt que par composants isolés.
00:11:14C'est l'étape où vous effectuez les tests d'intégration.
00:11:16Vous réalisez également des tests d'acceptation utilisateur, en recueillant les commentaires des utilisateurs réels pour les réintégrer dans le système.
00:11:24Vous effectuez des tests sur de multiples critères comme les biais, la conformité, les performances et d'autres dimensions liées aux risques afin de sécuriser la version avant sa mise en ligne.
00:11:32Et c'est aussi là que les critères de réussite changent du tout au tout.
00:11:35Dans le SDLC, vous mesuriez la justesse fonctionnelle avec des tests qui réussissaient ou échouaient tout simplement.
00:11:40Dans l'ADLC, vous mesurez la distribution de la précision, le taux d'hallucination et le coût par résultat, car aucun de ces éléments ne se résume à une simple réussite ou un échec.
00:11:48Le paradigme des tests évolue lui aussi.
00:11:50Dans le SDLC, des tests prédéfinis permettaient de valider des chemins de code connus.
00:11:54Dans l'ADLC, cela devient une évaluation continue du raisonnement, de la sécurité et de l'utilisation des outils, car l'agent n'emprunte jamais deux fois le même chemin de la même façon.
00:12:02Il existe plusieurs frameworks d'évaluation comme RAGAS et DEEPEVAL, mais l'élément principal qui valide la justesse est la performance de vos données par rapport aux indicateurs définis précédemment.
00:12:12Et il y a plusieurs manières de tester un système agentique, notamment par des tests fonctionnels, non fonctionnels, structurels et de charge.
00:12:18Chacun d'eux doit être mené rigoureusement, souvent en utilisant des systèmes agentiques eux-mêmes, afin que les cas limites soient correctement identifiés et corrigés avant la production.
00:12:27De plus, si vous appréciez notre contenu, pensez à cliquer sur le bouton de mention J'aime, car cela nous aide à produire plus de vidéos de ce genre et à toucher plus de monde.
00:12:34Une fois votre système prêt, il est temps de le déployer et de le mettre à disposition du monde réel.
00:12:39Vous ne le déployez pas directement en considérant que c'est terminé, car avec les systèmes agentiques, cela implique beaucoup plus de choses.
00:12:44Pour un système normal, le déploiement signifie généralement le pousser en production et surveiller la santé du système.
00:12:49Pour les systèmes agentiques, c'est totalement différent, et c'est ici que le sens même du déploiement change.
00:12:54Dans le SDLC, le déploiement marquait la fin du développement et le début d'une phase d'exploitation stable, le moment où le logiciel entrait dans sa phase de croisière.
00:13:02Dans l'ADLC, le déploiement est le point de départ d'une surveillance et d'un contrôle actifs, rythmés par les mises à jour de modèles, la dérive de contexte et les changements d'environnement en constante évolution.
00:13:11Ainsi, même si le développement est achevé, cette étape est d'autant plus critique que vous devez maintenant surveiller activement les indicateurs comportementaux et système.
00:13:19Vous avez également besoin de règles d'alerte qui surveillent en permanence les problèmes de qualité, de sécurité et de performance afin de les intercepter avant qu'ils ne se transforment en erreurs de production à grande échelle.
00:13:28Le déploiement est essentiellement une activation contrôlée accompagnée d'une observation continue pendant que de vrais utilisateurs interagissent avec le système.
00:13:34Au lieu de vous concentrer uniquement sur la santé du système, vous vous focalisez sur les performances comportementales pour détecter les anomalies au plus tôt.
00:13:41En pratique, vous proposez d'abord le système à un groupe restreint d'utilisateurs et les laissez l'utiliser en conditions réelles.
00:13:46Ensuite, vous observez comment le système agentique réagit au fil du temps avant de le déployer progressivement à l'ensemble des utilisateurs.
00:13:52Une fois que l'implémentation a franchi toutes les étapes, elle s'inscrit dans un cycle continu de maintenance, d'apprentissage et d'évolution.
00:13:58C'est une phase majeure car elle permet de maintenir la précision de l'agent et de l'aligner sur les besoins du monde réel.
00:14:03Avec les systèmes traditionnels, les boucles de rétroaction sont relativement simples.
00:14:06Un utilisateur signale un bug, et un développeur intervient pour le corriger.
00:14:10Avec les systèmes agentiques, c'est bien différent car ils reposent sur un processus d'amélioration continue qui ne s'arrête jamais.
00:14:16Le cycle affine constamment le modèle, et tous les signaux négatifs sont réinjectés pour perfectionner son comportement au fil du temps.
00:14:22Cela se fait généralement via des signaux dans l'interface, comme des pouces vers le haut ou vers le bas, pour capter le ressenti de l'utilisateur après une réponse.
00:14:29De nombreux systèmes en production exploitent déjà des mécanismes similaires, comme le choix entre plusieurs résultats ou le classement des réponses, comme on le voit dans ChatGPT ou Claude.
00:14:39Ces signaux sont ensuite réinjectés dans le système agentique pour qu'il apprenne et progresse vers de meilleures performances.
00:14:44Il y a également une mise à jour périodique des sources de données et des embeddings pour s'assurer que le système reste à jour et ne souffre pas d'informations obsolètes.
00:14:52L'alignement doit être surveillé en permanence afin que la sécurité et les garde-fous restent efficaces contre tous types de prompts, y compris les risques comme l'injection de prompts.
00:15:00Les variables clés ici sont la gestion continue des coûts, le suivi de la qualité, le backlog d'amélioration du produit et les mises à niveau des modèles, qui doivent tous être maintenus pour préserver la stabilité et la sécurité du système.
00:15:11Cela nous amène à la fin de cette vidéo.
00:15:13Si vous souhaitez soutenir la chaîne et nous aider à continuer à produire des vidéos comme celle-ci, vous pouvez le faire en utilisant le bouton Super Thanks ci-dessous.
00:15:20Comme toujours, merci d'avoir regardé et je vous donne rendez-vous dans la prochaine vidéo.

Key Takeaway

Le passage du SDLC à l'ADLC est indispensable pour gérer la nature probabiliste et changeante des agents d'IA à travers un cycle en 7 phases mêlant code, prompts, gestion stricte du contexte et boucle de rétroaction continue.

Highlights

  • Le cycle de vie du développement logiciel traditionnel (SDLC) considère le logiciel comme un élément statique et déterministe, tandis que le cycle de vie du développement agentique (ADLC) traite les systèmes d'IA comme des entités vivantes et probabilistes.

  • L'ADLC se compose de 7 phases distinctes conçues spécifiquement pour gérer le non-déterminisme et l'imprévisibilité des agents d'IA en production.

  • La phase de simulation et de preuve de valeur utilise des données réelles pour tester les prototypes et évaluer le retour sur investissement avant d'engager les coûts du développement complet.

  • Dans l'ADLC, la logique logicielle ne réside plus uniquement dans le code, mais se répartit entre le code, les prompts, les modèles choisis, les outils tiers et les protocoles de contexte comme les MCP.

  • Les critères de réussite des tests passent d'une validation binaire (succès ou échec) dans le SDLC à une mesure de la distribution de la précision, du taux d'hallucination et du coût par résultat dans l'ADLC.

  • Le déploiement d'un système agentique n'est pas une phase d'exploitation stable mais le point de départ d'une surveillance comportementale active pour détecter la dérive de contexte et les injections de prompts.

Timeline

L'insuffisance du SDLC face à l'essor des agents d'IA

  • Les systèmes logiciels actuels intégrant l'IA ne se comportent plus comme les anciens logiciels statiques.
  • Le cycle de vie du développement logiciel traditionnel (SDLC) s'avère insuffisant face aux outils comme Claude Code ou Cursor.
  • Le non-déterminisme des agents d'IA empêche de prédire le résultat d'un prompt avec une précision de 100 %.

Le développement logiciel a reposé pendant des décennies sur les étapes structurées du SDLC, allant de la conception à la maintenance. L'introduction de l'IA a transformé la phase de codage répétitif en un processus dynamique et vivant. Les décisions dépendent désormais du prompt, du contexte, du modèle et des outils externes, ce qui impose d'adopter le cycle de vie du développement agentique (ADLC) pour s'adapter à ce comportement probabiliste.

La phase 1 de l'ADLC : Préparation et formulation d'hypothèses

  • La première phase consiste à acquérir une compréhension concréte du probléme avant de concevoir le modèle.
  • L'identification des tâches répétitives manuelles détermine légitimement le périmètre d'action de l'agent d'IA.
  • L'utilisation d'un agent tiers aide à cartographier le comportement global du futur système.

Sauter cette phase initiale expose au risque d'automatiser les mauvaises tâches et d'aggraver la situation en production. Contrairement au déterminisme du SDLC, l'ADLC exige de formuler des hypothèses testables sur les flux de travail déjà existants. Le mode planification de l'agent d'IA doit être activé pour anticiper les interactions utilisateurs, les surcharges potentielles et les erreurs comportementales, plutôt que de se focaliser immédiatement sur l'architecture pure du code.

La phase 2 de l'ADLC : Définition du périmètre et modèle de responsabilité

  • L'analyse de faisabilité fixe des KPI techniques précis liés au temps, au coût et à la latence.
  • La cartographie d'un modèle de responsabilité homme-agent instaure une structure claire de responsabilisation.
  • La décision finale et la validation doivent impérativement incomber à un humain.

Cette phase transpose l'analyse des exigences métiers du SDLC vers l'environnement agentique. Elle définit les limites d'autonomie de l'agent d'IA afin de préserver la conformité et la sécurité juridique du système. En utilisant de nouveau le mode planification, l'agent intègre les scénarios de défaillance et documente explicitement les compromis acceptables, évitant ainsi de rejeter la faute sur le seul modèle en cas d'erreur de production.

La phase 3 de l'ADLC : Conception de l'architecture système de l'agent

  • Le choix des modèles de comportement inclut des approches comme ReAct, Plan-and-Act ou les systèmes multi-agents.
  • La planification économique des tokens et la compaction du contexte conditionnent la viabilité financière du projet.
  • La définition préalable des métriques de succès permet de guider la construction de l'agent via le TDD (Test-Driven Development).

L'architecture système doit impérativement réguler le flux de données entre les agents pour éviter toute dégradation des résultats. L'analyse intègre également la sélection des frameworks d'orchestration et des bases de données appropriées. Cette phase anticipe activement les problèmes futurs liés aux hallucinations, à la latence et au comportement multi-utilisateur grâce à un plan technique global généré en langage naturel.

La phase 4 de l'ADLC : Simulation, prototypage et preuve de valeur

  • La création de prototypes vérifie la validité des hypothèses initiales à un coût financier minimal.
  • La constitution d'un jeu de données de vérité terrain sert d'actif pour les futurs tests de régression.
  • Cette étape sert de barrière de validation pour décider de la poursuite ou de l'abandon du projet.

L'utilisation de données réelles permet de mesurer concrétement le taux d'hallucination, la précision des réponses et les benchmarks de coûts. C'est le moment où le retour sur investissement est analysé rigoureusement. Découvrir un échec de conception à ce stade évite les dommages financiers et réputationnels majeurs qu'entraînerait une mise en production prématurée.

La phase 5 de l'ADLC : Implémentation et gestion fine du contexte

  • La logique d'un système ADLC se fragmente entre le code, les prompts, les modèles et les services externes.
  • La centralisation de l'orchestration multi-agent, via des outils comme Claude Code, optimise la délégation des tâches.
  • La sélection et l'intégration des protocoles MCP (comme Google Calendar ou Gmail) enrichissent l'environnement d'exécution.

La gestion rigoureuse de la fenêtre de contexte est cruciale pour éviter l'accumulation d'informations superflues qui dégradent l'attention de l'agent. Le développement et la validation manuelle s'exécutent de manière imbriquée et continue du côté du développeur. Une modification mineure du prompt ou d'une dépendance pouvant altérer radicalement le comportement global, la validation ne peut pas être reportée à une étape ultérieure.

La phase 6 de l'ADLC : Stratégies de tests continus et d'évaluation

  • Les tests s'effectuent dans des conditions globales proches de la production plutôt que sur des composants isolés.
  • L'ADLC évalue en continu le raisonnement, la sécurité et l'usage des outils via des frameworks comme RAGAS ou DEEPEVAL.
  • Les tests fonctionnels, structurels et de charge exploitent souvent eux-mêmes d'autres systèmes agentiques.

Le paradigme change profondément par rapport au SDLC : les tests ne vérifient plus des chemins de code fixes mais valident la distribution des résultats face à un système qui n'emprunte jamais deux fois le même chemin. L'intégration intègre les retours d'expérience des utilisateurs réels pour corriger les cas limites. L'analyse porte spécifiquement sur les biais, les dimensions de risques et la conformité globale avant d'autoriser le déploiement.

La phase 7 de l'ADLC : Déploiement contrôlé et maintenance évolutive

  • Le déploiement marque le début d'une surveillance active des comportements et non une phase d'exploitation figée.
  • Le système requiert un déploiement progressif auprès d'un groupe d'utilisateurs restreint pour détecter les anomalies au plus tôt.
  • Les signaux négatifs de l'interface utilisateur alimentent directement la boucle d'apprentissage pour perfectionner le modèle.

Dans le cadre de l'ADLC, le déploiement doit faire face à la dérive de contexte, aux mises à jour de modèles et aux modifications d'environnement. Des règles d'alerte strictes interceptent les défaillances de sécurité, telles que les injections de prompts, avant qu'elles ne se propagent. La stabilité à long terme repose sur la mise à jour périodique des sources de données, des embeddings et sur une gestion stricte du budget lié aux tokens.

Community Posts

No posts yet. Be the first to write about this video!

Write about this video