WEBVTT 00:00:00.100 --> 00:00:03.280 Et si votre équipe de développement logiciel avait un coéquipier supplémentaire 00:00:03.280 --> 00:00:05.180 qui ne se fatigue jamais, apprend plus vite que quiconque 00:00:05.180 --> 00:00:08.020 et gère les tâches fastidieuses sans se plaindre ? 00:00:08.020 --> 00:00:10.120 C'est essentiellement ce que l'IA agentique est en train de devenir. 00:00:11.020 --> 00:00:14.140 Dans cette vidéo, nous définirons d'abord ce que signifie réellement l'IA agentique, 00:00:14.460 --> 00:00:17.440 nous montrerons comment elle s'intègre dans les flux de travail Donet et Azure 00:00:17.440 --> 00:00:20.300 et nous explorerons enfin son impact sur la productivité de votre équipe. 00:00:21.080 --> 00:00:24.680 A la fin, vous connaîtrez une petite expérience à essayer dans votre propre pipeline Donet cette semaine. 00:00:25.160 --> 00:00:26.720 Mais avant d'aborder les applications et les résultats, 00:00:26.720 --> 00:00:29.720 nous devons examiner ce qui différencie vraiment l'IA agentique des outils de saisie. 00:00:29.720 --> 00:00:31.820 semi-automatique que vous connaissez déjà. 00:00:33.120 --> 00:00:35.320 Qu'est-ce qui rend l'IA agentique différente ? 00:00:35.320 --> 00:00:38.260 Ce qui distingue l'IA agentique, ce n'est pas seulement sa capacité à générer du code, 00:00:38.600 --> 00:00:41.620 mais le fait qu'elle fonctionne comme un système de coéquipier aux compétences distinctes. 00:00:42.020 --> 00:00:44.140 Pour comprendre cela, nous pouvons le décomposer en trois triclés. 00:00:44.640 --> 00:00:46.800 La façon dont chaque agent conserve le contexte et la mémoire. 00:00:47.160 --> 00:00:49.140 La façon dont plusieurs agents se coordonnent comme une équipe. 00:00:49.520 --> 00:00:53.340 Et la différence entre une simple automatisation et une véritable automatisation et une véritable autonomie adaptative. 00:00:53.660 --> 00:00:55.640 Tout d'abord, examinons ce qui rend un agent individuel unique. 00:00:55.640 --> 00:00:58.020 Le contexte, la mémoire et l'orientation vers des objectifs. 00:00:58.020 --> 00:01:01.460 La saisie semi-automatique traditionnelle prédit le mot ou la ligne suivante, 00:01:01.600 --> 00:01:03.500 mais oublie tout le reste une fois la prédiction faite. 00:01:04.340 --> 00:01:07.460 Un agent IA, au contraire, possède une compréhension du projet dans sa globalité. 00:01:08.560 --> 00:01:10.020 Il se souvient de ce qui a déjà été essayé, 00:01:10.360 --> 00:01:12.780 c'est où se trouve le code et ajuste à sortir lorsque quelque chose change. 00:01:13.940 --> 00:01:16.140 Cette persistance leur approche du travail avec un développeur junior, 00:01:16.280 --> 00:01:20.120 quelqu'un qui apprend au fil du temps plutôt que de simplement deviner ce que vous voulez à l'instant T et à la différence T. 00:01:20.580 --> 00:01:22.980 La différence clé réside ici entre la prédiction et la planification. 00:01:22.980 --> 00:01:25.320 Au lieu de réagir à chaque frappe au clavier de manière isolée, 00:01:25.400 --> 00:01:28.040 un agent suit des objectifs et s'adapte à l'évolution des situations. 00:01:28.880 --> 00:01:30.980 Ensuite, voyons comment plusieurs agents travaillent ensemble. 00:01:31.420 --> 00:01:33.600 Une idée reçue très répandue consiste à considérer l'IA agentique 00:01:33.600 --> 00:01:36.600 comme un script de développement ou une macro qui automatise simplement des tâches répétitives. 00:01:36.920 --> 00:01:39.900 Mais dans les projets logiciels réels, le travail est réparti entre différents rôles. 00:01:40.860 --> 00:01:43.140 Architectes, relecteurs, testeurs, opérateurs, 00:01:43.360 --> 00:01:44.720 les agents peuvent refléter cette division, 00:01:44.880 --> 00:01:47.620 chacun gérant une partie du cycle de vie avec une mémoire, une cohérence parfaite. 00:01:48.380 --> 00:01:50.400 Imaginez un agent dédié à la conception du système, 00:01:50.560 --> 00:01:54.140 proposant des modèles d'architecture et des frameworks adaptés aux objectifs métiers. 00:01:55.160 --> 00:01:56.700 Un autre examine les modifications de code, 00:01:56.880 --> 00:01:59.380 détectant les problèmes tout en restant conscient de l'historique complet du projet. 00:02:00.220 --> 00:02:03.400 Un troisième pourrait étendre la couverture des tests en fonction des données utilisateurs, 00:02:03.700 --> 00:02:05.540 générant des cas de test sans que vous ayez à les demander. 00:02:06.400 --> 00:02:08.680 Chaque agent est spécialisé, mais il se coordonne comme une équipe, 00:02:08.680 --> 00:02:11.900 toujours disponible, toujours cohérent et facilement adaptable en fonction de la charge de travail. 00:02:12.920 --> 00:02:15.260 Là où les humains perdent en énergie, en contexte ou en concentration, 00:02:15.260 --> 00:02:17.860 les agents restent stables et mémorisent les détails avec précision. 00:02:18.760 --> 00:02:21.300 Le dernier point est la distinction entre automatisation et autonomie. 00:02:22.040 --> 00:02:23.880 L'automatisation existe depuis longtemps dans le développement. 00:02:24.360 --> 00:02:26.680 Pensez au script, au pipeline CISOCD et au modèle. 00:02:27.380 --> 00:02:28.360 Ceux-ci sont rigides par conception. 00:02:28.940 --> 00:02:30.920 Ils suivent des instructions exactes, étape par étape, 00:02:30.980 --> 00:02:33.340 mais ils échouent lorsque les conditions changent de façon inattendue. 00:02:33.980 --> 00:02:35.220 L'autonomie adopte une approche différente. 00:02:36.320 --> 00:02:37.940 Les agents IA peuvent réagir au changement à la volée 00:02:37.940 --> 00:02:39.880 en s'adaptant lorsqu'une version de dépendance change 00:02:39.880 --> 00:02:42.780 ou en reconsidérant un choix de service lorsque des contraintes de coût entrent en jeu. 00:02:42.780 --> 00:02:45.620 Au lieu d'exécuter des chemins prédéfinis, 00:02:45.720 --> 00:02:47.660 ils prennent des décisions dans des conditions dynamiques. 00:02:48.620 --> 00:02:51.280 C'est un passage de l'exécution statique à la résolution de problèmes adaptatifs. 00:02:51.880 --> 00:02:55.100 L'effet en aval est que ces agents ne se contentent plus d'attendre des commandes. 00:02:55.820 --> 00:02:57.620 Ils peuvent proposer des solutions lorsque des problèmes surviennent, 00:02:57.740 --> 00:03:00.160 souligner les risques avant qu'ils n'atteignent la production et rédiger des plans, 00:03:00.500 --> 00:03:02.180 qui économisent des heures de travail de configuration. 00:03:03.180 --> 00:03:05.520 Si le GitHub copilot d'aujourd'hui peut compléter des extraits de code, 00:03:05.860 --> 00:03:07.960 la version de demain gère davantage comme un contributeur de projet, 00:03:07.960 --> 00:03:11.000 définissant des feuilles de route, suggérant des stratégies de publication, 00:03:11.260 --> 00:03:13.980 voire signalant des décisions architecturales susceptibles de causer des problèmes par la suite. 00:03:14.400 --> 00:03:17.060 Cela ne signifie pas que chaque déploiement se fera sans intervention humaine, 00:03:17.360 --> 00:03:19.420 mais cela peut réduire considérablement les tâches répétitives 00:03:19.420 --> 00:03:22.120 et donner aux développeurs plus de temps pour se concentrer sur les aspects créatifs 00:03:22.120 --> 00:03:23.340 et à forte valeur ajoutés d'un projet. 00:03:23.800 --> 00:03:25.020 Et à forte valeur ajoutée d'un projet. 00:03:25.640 --> 00:03:27.820 Pour clarifier une formulation précédente dans ce domaine, au lieu de dire 00:03:27.820 --> 00:03:32.920 « Que se passe-t-il lorsque le provisionnement des ressources Azure ne nécessite aucune intervention humaine ? » 00:03:32.920 --> 00:03:34.220 Une déclaration plus précise serait 00:03:34.220 --> 00:03:37.140 « Ces outils peuvent réduire la quantité de configuration manuelle nécessaire 00:03:37.140 --> 00:03:41.080 tout en gardant les garde-fous essentiels sous contrôle humain. » 00:03:41.080 --> 00:03:44.680 Le résultat reste transformateur sans suggérer que la supervision humaine disparaisse complètement. 00:03:46.240 --> 00:03:47.920 La prise de conscience majeure est que 00:03:47.920 --> 00:03:51.860 « Liage antique n'est pas juste un autre plugin qui accélère une tâche ici ou là » 00:03:51.860 --> 00:03:54.160 Elle commence à fonctionner comme un membre à part entière de l'équipe, 00:03:54.400 --> 00:03:57.280 gérant le travail de fond pour que les développeurs ne soient pas coincés à suivre des détails 00:03:57.280 --> 00:03:59.340 qui auraient pu être gérés par un homologue toujours actif. 00:04:00.540 --> 00:04:02.080 La capacité de toute l'équipe est amplifiée, 00:04:02.380 --> 00:04:05.460 car des agents numériques travaillent aux côtés des spécialistes humains dans des domaines clés. 00:04:06.500 --> 00:04:08.120 Comprendre la théorie est important, mais ce qui compte vraiment, 00:04:08.240 --> 00:04:10.520 c'est la façon dont cela se manifeste dans des environnements familiers. 00:04:11.240 --> 00:04:12.120 Voici donc les cas de curiosité. 00:04:12.580 --> 00:04:14.480 Qu'est-ce qui change réellement au premier jour d'un nouveau projet, 00:04:14.660 --> 00:04:17.360 lorsque les agents sont actifs dès le début ? 00:04:17.360 --> 00:04:20.420 Ensuite, nous examinerons un scénario concret au sein de l'équasystème Toinette 00:04:20.420 --> 00:04:21.720 où ces changements commencent à apparaître 00:04:21.720 --> 00:04:24.120 avant même que vous ayez écrit votre première ligne de code. 00:04:24.120 --> 00:04:27.320 Réimaginer le flux de travail des développeurs dans le Donnet. 00:04:27.560 --> 00:04:28.560 Dans le développement Donnet, 00:04:28.720 --> 00:04:31.540 le changement le plus visible commence par la façon dont les projets démarrent. 00:04:32.960 --> 00:04:36.080 Réimaginer le flux de travail des développeurs ici se résume à trois avantages tactiques. 00:04:37.000 --> 00:04:38.420 Un échafaudage d'architecture plus rapide, 00:04:38.660 --> 00:04:40.060 critique au niveau du projet au fur et à mesure, 00:04:40.380 --> 00:04:41.900 et une baisse notable de la fatigue liée à la configuration. 00:04:42.840 --> 00:04:44.080 Le premier est l'échafaudage accéléré. 00:04:44.720 --> 00:04:46.880 Au lieu d'ouvrir Visual Studio face à une solution vide, 00:04:46.880 --> 00:04:49.920 un agent IA peut vous proposer des options d'architecture adaptées 00:04:49.920 --> 00:04:51.320 à votre cas d'usage précis. 00:04:52.280 --> 00:04:54.120 Pour une API web avec des mises à jour en temps réel, 00:04:54.560 --> 00:04:56.100 l'agent suggère une conception en couche propre 00:04:56.100 --> 00:04:58.080 et souligne l'intégration naturelle de signalaires. 00:04:59.100 --> 00:05:00.280 Pour une application financière, 00:05:00.360 --> 00:05:02.280 il configure Entity Framework avec un type H4 00:05:02.280 --> 00:05:03.640 et l'intégration d'Azure Active Directory 00:05:03.640 --> 00:05:05.260 avant même que vous n'ayez créé le moindre dossier. 00:05:06.660 --> 00:05:08.480 Ce qui prend normalement des heures de recherche ou des réunions 00:05:08.480 --> 00:05:10.460 est condensé en quelques points de départ personnalisés. 00:05:11.280 --> 00:05:12.700 Il ne s'agit pas de plans finaux, cependant. 00:05:12.740 --> 00:05:13.700 Ce sont des ébauches. 00:05:14.040 --> 00:05:16.660 Les équipes doivent valider chaque suggestion via une rapide liste de vérifications. 00:05:17.380 --> 00:05:19.380 L'authentification répond-elle aux exigences ? 00:05:19.380 --> 00:05:21.040 La journalisation est-elle correctement configurée ? 00:05:21.040 --> 00:05:22.260 Les cas de tests de base ont été en place. 00:05:23.000 --> 00:05:24.720 Cette gouvernance légère garantit que la rapidité 00:05:24.720 --> 00:05:25.940 ne se fait pas au détriment de la stabilité. 00:05:26.560 --> 00:05:28.040 Le deuxième avantage est la critique continue. 00:05:29.080 --> 00:05:30.580 Voyez cela moins comme de l'autocomplétion 00:05:30.580 --> 00:05:33.180 et davantage comme un conseiller veillant à la cohérence de la conception. 00:05:34.640 --> 00:05:36.400 Si vous créez un modèle de dépôt pour l'accès aux données, 00:05:36.620 --> 00:05:39.380 l'agent vous signale si vous vous éloignez de la séparation des préoccupations. 00:05:40.200 --> 00:05:41.220 Ajoutez un nouveau contrôleur 00:05:41.220 --> 00:05:43.000 et il propose des tests unitaires correspondants 00:05:43.000 --> 00:05:45.020 ou souligne des incohérences avec le reste du projet. 00:05:46.020 --> 00:05:47.460 Au lieu de vous laisser avec du code standard, 00:05:47.700 --> 00:05:49.260 il oriente la structure de votre système, 00:05:49.380 --> 00:05:51.640 vers des modèles maintenables à chaque commit. 00:05:52.180 --> 00:05:53.100 Pour une expérience pratique, 00:05:53.480 --> 00:05:55.300 essayez d'activer Copilot dans Visual Studio 00:05:55.300 --> 00:05:57.680 sur un petit prototype ASP.net Core. 00:05:58.740 --> 00:05:59.960 Comparez ensuite le temps nécessaire 00:05:59.960 --> 00:06:01.600 pour traiter la première requête significative 00:06:01.600 --> 00:06:03.740 avec un point de terminaison authentifié persistant 00:06:03.740 --> 00:06:05.380 par rapport à une approche manuelle. 00:06:06.760 --> 00:06:07.980 Ce n'est pas une garantie de gain de temps, 00:06:08.200 --> 00:06:09.560 mais réaliser cet exercice comparatif 00:06:09.560 --> 00:06:10.600 dans votre propre environnement 00:06:10.600 --> 00:06:11.720 est souvent le moyen le plus rapide 00:06:11.720 --> 00:06:13.360 d'évaluer l'impact réel de ces agents. 00:06:13.360 --> 00:06:16.460 Le troisième avantage est la réduction de la configuration 00:06:16.460 --> 00:06:17.120 et de la charge unique. 00:06:17.860 --> 00:06:19.700 Une grande partie du travail initial est répétitive. 00:06:20.040 --> 00:06:21.000 Configurer l'authentification, 00:06:21.200 --> 00:06:22.120 importer des paquets Nougat, 00:06:22.240 --> 00:06:24.240 paramétrer la journalisation avec Application Insights 00:06:24.240 --> 00:06:25.540 ou rédiger des pipelines YAML. 00:06:26.800 --> 00:06:28.780 Un agent peut générer ces éléments immédiatement, 00:06:28.920 --> 00:06:30.200 incluant des tests d'intégration 00:06:30.200 --> 00:06:31.640 qui connaissent les dépendances présentes. 00:06:32.420 --> 00:06:33.420 Cela ne vous retire pas le contrôle, 00:06:33.540 --> 00:06:35.180 cela déplace l'endroit où vous investissez votre énergie. 00:06:35.180 --> 00:06:37.000 Au lieu de lutter contre les fichiers de configuration 00:06:37.000 --> 00:06:37.620 toute la journée, 00:06:37.880 --> 00:06:39.120 vous consacrez ce temps à implémenter 00:06:39.120 --> 00:06:40.400 la logique métier qui compte vraiment. 00:06:41.520 --> 00:06:43.260 La fatigue liée à la configuration disparaît, 00:06:43.420 --> 00:06:44.300 libérant de la bande passante 00:06:44.300 --> 00:06:45.640 pour des décisions de conception créative 00:06:45.640 --> 00:06:46.600 plutôt que des tâches mécaniques. 00:06:47.300 --> 00:06:49.280 La différence avec l'automatisation traditionnelle 00:06:49.280 --> 00:06:50.260 réside dans la flexibilité. 00:06:50.740 --> 00:06:51.740 Un modèle de projet vous fournit 00:06:51.740 --> 00:06:52.760 des paramètres statiques par défaut. 00:06:53.340 --> 00:06:54.720 Un agent adapte son échafaudage 00:06:54.720 --> 00:06:56.260 en fonction de votre objectif métier déclaré. 00:06:56.840 --> 00:06:58.300 Si vous développez une application collaborative, 00:06:58.660 --> 00:06:59.620 des stratégies de mise en cache 00:06:59.620 --> 00:07:01.120 comme Redis et une conception événementielle 00:07:01.120 --> 00:07:01.980 avec Azure Service Bus 00:07:01.980 --> 00:07:03.260 apparaissent dans le plan généré. 00:07:03.260 --> 00:07:06.160 Si vous vous orientez vers des charges de travail planifiées, 00:07:06.220 --> 00:07:06.920 des services d'arrière-plan 00:07:06.920 --> 00:07:08.440 et le traitement de fil d'attente s'affiche alors. 00:07:09.060 --> 00:07:10.720 Cette réactivité distingue l'IA agentique 00:07:10.720 --> 00:07:11.580 du simple scripting 00:07:11.580 --> 00:07:13.120 en proposant des recommandations 00:07:13.120 --> 00:07:14.540 qui imitent le rôle d'un membre senior 00:07:14.540 --> 00:07:16.440 guidant les décisions initiales. 00:07:16.820 --> 00:07:18.900 Le contraste avec l'utilisation actuelle de copilote est frappant. 00:07:19.500 --> 00:07:20.780 Pour l'instant, la plupart des développeurs 00:07:20.780 --> 00:07:22.660 le voient comme un moyen d'accélérer la syntaxe courante 00:07:22.660 --> 00:07:23.360 ou le code standard. 00:07:24.380 --> 00:07:26.080 Pose une question, l'outil complète la ligne. 00:07:27.260 --> 00:07:28.400 Avec les capacités des agents, 00:07:28.400 --> 00:07:30.600 l'outil commence à conseiller au niveau système 00:07:30.600 --> 00:07:32.400 proposant des alternatives contextuelles 00:07:32.400 --> 00:07:34.400 et soulevant les compromis dès le début du cycle. 00:07:35.440 --> 00:07:37.580 Le saut consiste à passer de la génération d'extraits de code 00:07:37.580 --> 00:07:38.960 à la conception de solutions viables. 00:07:39.640 --> 00:07:41.260 Cela change non seulement la façon dont le code est écrit, 00:07:41.340 --> 00:07:43.460 mais aussi la façon dont les équipes structurent la solution 00:07:43.460 --> 00:07:44.820 avant de s'engager dans une direction, 00:07:45.080 --> 00:07:45.680 avant d'une direction. 00:07:46.320 --> 00:07:48.340 Rien de tout cela ne supprime le besoin du jugement humain. 00:07:49.120 --> 00:07:50.380 Les agents peuvent suggérer des frameworks, 00:07:50.500 --> 00:07:51.460 des dépendances et des pratiques, 00:07:51.560 --> 00:07:53.140 mais leur vérification incombe toujours à l'équipe. 00:07:53.980 --> 00:07:55.060 Considérez chaque recommandation 00:07:55.060 --> 00:07:56.080 comme une proposition préliminaire. 00:07:56.520 --> 00:07:58.180 Acceptez les éléments conformes à vos standards, 00:07:58.660 --> 00:08:00.000 révisez les autres et tirez des leçons 00:08:00.000 --> 00:08:01.700 pour la prochaine itération du projet. 00:08:02.860 --> 00:08:04.060 L'IA gère le travail répétitif, 00:08:04.140 --> 00:08:05.540 tandis que les membres de l'équipe restent concentrés 00:08:05.540 --> 00:08:07.460 sur l'alignement des choix technologiques avec la stratégie. 00:08:08.140 --> 00:08:09.700 Jusqu'ici, nous avons vu comment les agents 00:08:09.700 --> 00:08:11.820 remodèlent l'expérience de codage au sein de Donnet. 00:08:12.020 --> 00:08:13.460 Mais leur implication ne s'arrête pas 00:08:13.460 --> 00:08:16.300 à la conception ou à la structure du projet, ou à. 00:08:16.840 --> 00:08:17.840 Une fois les bases posées, 00:08:17.980 --> 00:08:19.680 cette même intelligence s'étend au provisionnement, 00:08:19.820 --> 00:08:22.020 au déploiement et à la gestion de l'infrastructure 00:08:22.020 --> 00:08:23.260 dont dépendent ces applications. 00:08:24.600 --> 00:08:26.360 C'est là qu'une autre transformation majeure prend forme 00:08:26.360 --> 00:08:28.600 et elle ne se limite pas au flux de travail local du développeur. 00:08:28.600 --> 00:08:30.940 Il s'agit de l'environnement cloud qui l'entoure. 00:08:32.220 --> 00:08:34.000 Des agents cloud faisant fonctionner Azure en pilotage automatique. 00:08:34.480 --> 00:08:35.740 Tournons notre attention vers ce qui se passe 00:08:35.740 --> 00:08:36.820 lorsque la gestion d'Azure elle-même 00:08:36.820 --> 00:08:38.860 commence à fonctionner en pilotage automatique grâce aux agents. 00:08:39.960 --> 00:08:41.800 La manière dont cette discussion est initialement présentée 00:08:41.800 --> 00:08:42.800 ressemble souvent à la science-fiction. 00:08:43.100 --> 00:08:44.980 Que se passe-t-il lorsque le provisionnement des ressources Azure 00:08:44.980 --> 00:08:46.600 ne nécessite plus aucune intervention humaine ? 00:08:48.000 --> 00:08:49.580 Une meilleure façon d'aborder la question est la suivante. 00:08:50.280 --> 00:08:52.260 Que se passe-t-il lorsque le provisionnement de routine 00:08:52.260 --> 00:08:54.660 et la détection de dérive nécessitent moins d'intervention manuelle, 00:08:54.660 --> 00:08:57.500 car les agents gèrent des tâches répétitives sous des garde-fous définies, 00:08:57.680 --> 00:08:59.220 sous des garde-fous définies ? 00:08:59.220 --> 00:09:01.440 Ce changement est important car il ne s'agit pas de supprimer les humains 00:09:01.440 --> 00:09:03.940 mais de décharger le travail répétitif tout en conservant une supervision, 00:09:04.200 --> 00:09:05.060 tout en conservant une supervision. 00:09:05.200 --> 00:09:07.200 Si vous avez déjà construit un environnement Azure complexe, 00:09:07.240 --> 00:09:08.920 vous savez à quel point cela peut devenir désordonné. 00:09:09.680 --> 00:09:11.900 Vous jonglez avec des modèles, des scripts et du I, 00:09:12.000 --> 00:09:12.740 YAML de pipeline, 00:09:13.080 --> 00:09:15.040 tout en alternant entre les commandes CLI pour la vitesse 00:09:15.040 --> 00:09:16.240 et le portail pour les exceptions. 00:09:17.200 --> 00:09:18.520 Chaque raccourci devient une dette technique 00:09:18.520 --> 00:09:19.520 qui ne demande qu'à refaire surface. 00:09:20.280 --> 00:09:22.060 Une machine virtuelle laissée en marche hors des heures, 00:09:22.200 --> 00:09:23.340 des coûts augmentant sans préavis 00:09:23.340 --> 00:09:24.960 ou un compte de stockage exposé par erreur. 00:09:25.940 --> 00:09:26.860 Et dans les opérations cloud, 00:09:27.000 --> 00:09:29.000 même les petites erreurs créent des maux de tête disproportionnés. 00:09:29.840 --> 00:09:30.860 Des factures qui explosent, 00:09:30.980 --> 00:09:32.360 des régions qui compromettent la résilience 00:09:32.360 --> 00:09:34.660 ou des lacunes de conformité découvertes au pire moment possible. 00:09:35.580 --> 00:09:37.740 C'est le travail fastidieux dont la plupart des équipes veulent se libérer. 00:09:37.920 --> 00:09:39.180 Et c'est là qu'un agent commence à ressembler 00:09:39.180 --> 00:09:40.500 à un ingénieur de déploiement autonome. 00:09:41.060 --> 00:09:41.580 L'idée est simple. 00:09:42.220 --> 00:09:43.860 Vous fournissez des objectifs commerciaux, 00:09:44.080 --> 00:09:45.100 des exigences de performance, 00:09:45.400 --> 00:09:46.320 des besoins de récupération, 00:09:46.480 --> 00:09:47.300 des règles de conformité, 00:09:47.300 --> 00:09:48.440 et des tolérances budgétaires 00:09:48.440 --> 00:09:51.020 et l'agent traduit cette intention en configuration d'infrastructure. 00:09:51.980 --> 00:09:53.220 Au lieu de passer d'une console à l'autre 00:09:53.220 --> 00:09:54.640 ou d'assembler des identifiants manuellement, 00:09:54.900 --> 00:09:57.580 voyez des modèles IASC déjà alignés sur vos objectifs exprimés. 00:09:58.580 --> 00:10:00.220 A partir de là, ce même agent reste en veille, 00:10:00.700 --> 00:10:01.980 effectue des contrôles de conformité, 00:10:02.400 --> 00:10:04.140 simule les erreurs de configuration possibles 00:10:04.140 --> 00:10:05.640 et applique les correctifs proposés 00:10:05.640 --> 00:10:07.240 avant que les problèmes ne s'aggravent en production. 00:10:08.140 --> 00:10:09.720 La différence avec l'automatisation existante 00:10:09.720 --> 00:10:10.740 réside dans l'adaptabilité. 00:10:11.480 --> 00:10:13.840 Un pipeline CICD classique considère vos définitions YAML 00:10:13.840 --> 00:10:15.100 comme une vérité absolue. 00:10:15.100 --> 00:10:17.500 Elle fonctionne jusqu'à ce que la réalité change, 00:10:17.600 --> 00:10:18.680 qu'une dépendance soit mise à jour, 00:10:18.780 --> 00:10:19.740 qu'un pic de demande survienne 00:10:19.740 --> 00:10:21.360 ou qu'un nouveau mandat de conformité apparaisse. 00:10:21.500 --> 00:10:23.160 Et alors ces instructions statiques échouent 00:10:23.160 --> 00:10:24.800 ou valident quelque chose qui semble correct 00:10:24.800 --> 00:10:26.540 mais ne répond pas aux besoins de l'entreprise. 00:10:27.600 --> 00:10:29.340 Un pipeline piloté par agent se comporte différemment. 00:10:29.740 --> 00:10:31.020 Il traite ces définitions comme des bases 00:10:31.020 --> 00:10:32.880 mais les met à jour lorsque les conditions changent. 00:10:34.340 --> 00:10:36.220 Au lieu d'attendre qu'une personne mette à l'échelle un service 00:10:36.220 --> 00:10:37.640 ou ajuste la distribution régionale, 00:10:37.760 --> 00:10:39.280 il détecte les modèles de charge, 00:10:39.400 --> 00:10:40.280 prédit les seuils probables 00:10:40.280 --> 00:10:42.540 et provisionne de la capacité supplémentaire à l'avance. 00:10:42.540 --> 00:10:46.940 Cette adaptabilité rend les scénarios moins sujets aux erreurs dans la pratique. 00:10:47.320 --> 00:10:49.820 Imaginez une application de données traitant du trafic principalement aux Etats-Unis. 00:10:50.560 --> 00:10:52.460 Une semaine plus tard, de nouveaux utilisateurs apparaissent en Europe. 00:10:53.000 --> 00:10:55.180 La latence augmente mais personne n'avait prévu une autre région, 00:10:55.340 --> 00:10:56.080 dans le YAML original. 00:10:57.020 --> 00:10:58.320 L'automatisation traditionnelle ignore. 00:10:58.780 --> 00:11:00.700 Vous ne vous en rendez compte qu'après les plaintes et l'analyse des logs. 00:11:01.280 --> 00:11:02.840 A l'inverse, un agent signale la tendance, 00:11:02.920 --> 00:11:04.000 déploie une réplique européenne 00:11:04.000 --> 00:11:06.740 et configure le routage via Azure Front Door immédiatement. 00:11:07.300 --> 00:11:08.740 Il ne se contente pas de déployer et de s'arrêter là. 00:11:08.740 --> 00:11:10.740 Il aligne constamment les ressources avec l'intention initiale. 00:11:11.780 --> 00:11:13.960 Presque comme un opérateur disponible 24h24 et 16h10, 00:11:14.080 --> 00:11:16.100 le véritable avantage va au-delà de la mise à l'échelle. 00:11:16.920 --> 00:11:18.960 La sécurité et la conformité sont intégrés dans la boucle. 00:11:19.520 --> 00:11:22.740 Cela peut se traduire par un agent observant un conteneur de stockage exposé par erreur, 00:11:22.900 --> 00:11:26.200 le verrouillant automatiquement ou détectant une dérive dans la base de corrective 00:11:26.200 --> 00:11:28.400 d'une machine virtuelle et la remettant en conformité. 00:11:29.020 --> 00:11:30.920 Ce sont des tâches à haute fréquence et faible visibilité 00:11:30.920 --> 00:11:32.460 que les humains détectent généralement plus tard 00:11:32.460 --> 00:11:34.000 et seulement après un effort considérable. 00:11:34.000 --> 00:11:37.540 En les intégrant dans un cycle continu, vous ne supprimez pas les opérateurs, 00:11:37.640 --> 00:11:38.840 vous les libérez. 00:11:39.720 --> 00:11:41.180 Au lieu de passer leur énergie à gérer les urgences, 00:11:41.260 --> 00:11:43.420 ils se concentrent sur la planification et la stratégie de haut niveau. 00:11:43.980 --> 00:11:44.700 Et c'est une nuance importante. 00:11:45.420 --> 00:11:46.540 La supervision humaine ne disparaît pas. 00:11:46.900 --> 00:11:47.540 Votre rôle change. 00:11:47.920 --> 00:11:49.140 Au lieu de cocher des cases ligne par ligne, 00:11:49.260 --> 00:11:50.680 vous définissez les directives dès le départ. 00:11:51.760 --> 00:11:53.020 Quelles régions sont autorisées ? 00:11:53.020 --> 00:11:54.320 Quels coûts sont acceptables ? 00:11:54.320 --> 00:11:57.380 Quelles normes de conformité ne peuvent être enfreintes ? 00:11:57.380 --> 00:11:59.540 Une étape pratique pour toute équipe curieuse de tester cela 00:11:59.540 --> 00:12:01.380 est de définir des garde-fous politiques rapidement, 00:12:01.380 --> 00:12:04.060 fixer des plafonds de coûts, désigner les régions approuvées 00:12:04.060 --> 00:12:05.460 et ajouter des limites de conformité. 00:12:06.540 --> 00:12:09.380 L'agent agit alors comme un garant et non comme un opérateur sans contrainte. 00:12:09.920 --> 00:12:10.780 C'est le principe directeur. 00:12:11.460 --> 00:12:13.060 Vous gardez le contrôle de l'orientation stratégique 00:12:13.060 --> 00:12:15.560 tandis que l'agent exécute les mesures de protection à grande échelle. 00:12:16.240 --> 00:12:19.040 Cela ne signifie pas non plus que vous devez confier la production à l'agent dès le premier jour. 00:12:19.600 --> 00:12:22.220 Si vous êtes réticent au risque, commencez dans un environnement de test contrôlé. 00:12:22.900 --> 00:12:24.480 Exposez l'agent à une charge de travail non critique 00:12:24.480 --> 00:12:27.400 ou sélectionnez un seul service comme l'infrastructure de stockage ou de journalisation 00:12:27.400 --> 00:12:29.540 et laissez-le gérer la dérive et le provisionnement. 00:12:29.540 --> 00:12:31.880 De cette façon, vous développez votre confiance 00:12:31.880 --> 00:12:34.240 dans la manière dont il interprète les garde-fous avant d'étendre son champ d'action. 00:12:35.080 --> 00:12:36.700 Considérez cela comme la conduite d'un projet pilote 00:12:36.700 --> 00:12:38.420 avec une portée bien définie et des enjeux faibles, 00:12:38.740 --> 00:12:41.560 exactement comme la plupart des pratiques DevOps fiables évoluent. 00:12:42.440 --> 00:12:44.160 Au fond, une approche agentique d'Azure IRC 00:12:44.160 --> 00:12:46.280 ressemble moins à l'écriture de dizaines de scripts statiques 00:12:46.280 --> 00:12:49.200 qu'à la gestion d'une liste de contrôle dynamique qu'à la gestion dynamique. 00:12:49.780 --> 00:12:52.180 Générer des modèles, exécuter des vérifications pré-déploiement, 00:12:52.460 --> 00:12:54.160 surveiller les dérives et proposer des correctifs, 00:12:54.720 --> 00:12:55.960 le tout dans les limites que vous configurez. 00:12:56.860 --> 00:12:58.200 C'est assez structuré pour inspirer confiance, 00:12:58.200 --> 00:13:00.340 mais assez flexible pour évoluer lorsque les conditions changent. 00:13:01.240 --> 00:13:03.240 Bien sûr, le provisionnement et la mise à l'échelle de l'infrastructure 00:13:03.240 --> 00:13:04.420 ne sont qu'un aspect de la fiabilité. 00:13:05.500 --> 00:13:07.300 Le problème le plus ardu survient souvent plus tard. 00:13:07.620 --> 00:13:09.500 S'assurer que le code déployé sur cet environnement 00:13:09.500 --> 00:13:11.060 résiste réellement aux conditions réelles. 00:13:12.260 --> 00:13:13.860 C'est là que le défi suivant commence à apparaître, 00:13:14.000 --> 00:13:16.440 la question de détecter les bugs que les humains ne voient tout simplement pas 00:13:16.440 --> 00:13:17.920 avant qu'ils ne soient en production. 00:13:19.040 --> 00:13:21.340 Test autonome, bug que les humains manquent ? 00:13:21.340 --> 00:13:23.340 Les tests ne couvrent que ce que les humains peuvent imaginer. 00:13:23.580 --> 00:13:24.900 Et c'est là la limite fondamentale. 00:13:24.900 --> 00:13:27.840 La plupart des défaillances en production ne viennent pas de ce qui est anticipé, 00:13:28.140 --> 00:13:30.140 mais de ce qui échappe à l'imagination humaine. 00:13:30.840 --> 00:13:32.640 Les agents de tests autonomes comblent cette lacune 00:13:32.640 --> 00:13:34.780 en se concentrant sur les cas limites et les conditions dynamiques 00:13:34.780 --> 00:13:36.720 qui n'intègreraient jamais une suite de tests classiques 00:13:36.720 --> 00:13:39.560 qui a classique considérée la condition de concurrence hors du changement d'échelle. 00:13:39.840 --> 00:13:42.120 Une application de Wadnet sur Azure peut fonctionner parfaitement 00:13:42.120 --> 00:13:44.260 sous une charge élevée lors d'un test de stress planifié. 00:13:44.760 --> 00:13:46.300 Mais introduisez des événements de mise à l'échelle, 00:13:46.420 --> 00:13:47.800 de nouvelles instances lancées en plein trafic 00:13:47.800 --> 00:13:49.800 et soudain des erreurs de gestion de session apparaissent. 00:13:49.800 --> 00:13:52.960 À moins que quelqu'un n'ait conçu un test spécifiquement pour ce chevauchement, 00:13:53.060 --> 00:13:53.740 il passe inaperçu. 00:13:54.700 --> 00:13:56.480 Un agent autonome repère l'anomalie, l'isole 00:13:56.480 --> 00:13:59.560 et génère un nouveau test de régression autour de cette condition, autour de cette condition. 00:13:59.780 --> 00:14:01.160 La prochaine fois que la mise à l'échelle se produit, 00:14:01.260 --> 00:14:02.360 cette protection est déjà présente, 00:14:02.500 --> 00:14:04.880 transformant ce qui était un risque caché en un scénario surveillé. 00:14:05.240 --> 00:14:06.640 Un autre exemple est la mutation des entrées. 00:14:07.160 --> 00:14:08.820 Les testeurs humains conçoivent généralement leurs tests 00:14:08.820 --> 00:14:10.260 avec des données sûres ou prévisibles à l'esprit. 00:14:10.800 --> 00:14:12.020 Nom d'utilisateur valide, 00:14:12.340 --> 00:14:14.040 charge utile d'API correct ou qu'elle limite évident, 00:14:14.180 --> 00:14:14.820 comme les chaînes vides. 00:14:15.960 --> 00:14:16.960 Un agent, en revanche, 00:14:16.960 --> 00:14:19.620 commence à expérimenter des variations auxquelles les développeurs ne penseraient pas. 00:14:19.860 --> 00:14:19.960 Pas. 00:14:20.760 --> 00:14:21.640 Requêtes surdimensionnées, 00:14:21.840 --> 00:14:22.560 encodage étrange, 00:14:22.820 --> 00:14:24.460 léger délai entre les appels en plusieurs étapes. 00:14:25.580 --> 00:14:26.880 Ce faisant, il peut provoquer des échecs 00:14:26.880 --> 00:14:28.760 que les suites de tests manuels ignoreraient totalement. 00:14:29.200 --> 00:14:31.240 La valeur ne réside pas seulement dans la vitesse, mais dans la diversité. 00:14:31.820 --> 00:14:34.260 Les agents explorent les recoins étranges des espaces d'entrée plus rapidement 00:14:34.260 --> 00:14:35.200 qu'on ne pourrait jamais le faire, 00:14:35.280 --> 00:14:36.600 des cas scénarisés par des humains. 00:14:37.140 --> 00:14:39.220 Ce qui distingue ce changement de l'automatisation traditionnelle, 00:14:39.320 --> 00:14:40.600 c'est l'évolution de la suite de tests. 00:14:41.120 --> 00:14:44.020 Un pack de régression conçu par des humains reste relativement statique. 00:14:44.020 --> 00:14:47.320 Ils reflètent les connaissances et les hypothèses de l'équipe à un moment donné. 00:14:48.360 --> 00:14:50.060 Les agents transforment cela en un processus continu. 00:14:50.500 --> 00:14:52.520 Ils enrichissent la suite au rythme des changements du système, 00:14:52.680 --> 00:14:54.000 explorant toujours les états imprévus. 00:14:55.560 --> 00:14:57.940 Au lieu que les développeurs mettent péniblement à jour des scripts fragiles 00:14:57.940 --> 00:14:59.280 après chaque itération, de nouveaux cas, 00:14:59.660 --> 00:15:02.360 sont généles et dynamiquement à partir d'observations réelles du comportement du système. 00:15:03.720 --> 00:15:05.060 Cependant, il existe une mise en garde importante. 00:15:05.360 --> 00:15:08.280 Tous les tests générés par des agents ne méritent pas d'intégrer votre suite permanente. 00:15:08.860 --> 00:15:10.880 Les tests instables ou non pertinents peuvent s'accumuler rapidement, 00:15:10.880 --> 00:15:13.200 faisant perdre du temps et minant la confiance envers l'automatisation. 00:15:14.020 --> 00:15:15.500 Et pourquoi la gouvernance est essentielle ? 00:15:15.500 --> 00:15:16.760 Les équipes ont besoin d'un processus de rue. 00:15:17.080 --> 00:15:20.360 Les développeurs ou ingénieurs QID doivent valider chaque test proposé 00:15:20.360 --> 00:15:22.180 pour sa stabilité et sa pertinence métier 00:15:22.180 --> 00:15:24.180 avant de l'ajouter au pack de régression stable. 00:15:25.040 --> 00:15:26.160 Comme pour toute automatisation, 00:15:26.340 --> 00:15:28.760 la supervision garantit que ces outils renforcent la fiabilité 00:15:28.760 --> 00:15:30.620 au lieu de noyer les équipes sous le bruit. 00:15:31.680 --> 00:15:34.260 Une autre idée reçue à dissiper est que les agents corrigent les bugs. 00:15:35.700 --> 00:15:38.120 Ils ne réécrivent pas le code de production et ne corrigent pas les failles de nœud. 00:15:38.260 --> 00:15:39.460 Ce qu'ils font exceptionnellement bien, 00:15:39.540 --> 00:15:42.420 c'est mettre en évidence des scénarios reproductibles avec des détails de diagnostic clair. 00:15:42.420 --> 00:15:45.440 Pour un développeur, disposer d'étapes capturées par un agent 00:15:45.440 --> 00:15:48.020 fait la différence entre des heures de conjecture et une résolution rapide. 00:15:48.900 --> 00:15:50.920 Dans certains cas, les agents peuvent suggérer une solution 00:15:50.920 --> 00:15:51.960 basée sur des modèles connus, 00:15:52.040 --> 00:15:54.840 mais la décision finale et le changement restent entre des mains humaines. 00:15:55.740 --> 00:15:57.980 Vu sous cet angle, la répartition du travail devient plus claire. 00:15:58.460 --> 00:16:00.820 Les machines découvrent, les humains jugent et réparent. 00:16:01.360 --> 00:16:03.260 L'impact commercial se traduit par moins de gestion de crise. 00:16:04.200 --> 00:16:06.080 Les équipes voient moins de tickets de fin de soirée, 00:16:06.580 --> 00:16:08.040 moins de régressions après les mises en production 00:16:08.040 --> 00:16:11.000 et une baisse notable du temps perdu à reproduire les problèmes. 00:16:12.380 --> 00:16:15.040 Les problèmes de performance sont détectés dans des environnements contrôlés 00:16:15.040 --> 00:16:17.020 au lieu d'apparaître devant les utilisateurs finaux. 00:16:17.620 --> 00:16:19.860 Les erreurs de sécurité sont mises en lumière lors des tests internes. 00:16:20.400 --> 00:16:22.480 Pas après un scan de conformité ou un test d'intrusion. 00:16:23.180 --> 00:16:25.760 Ce changement permet à la QA de se concentrer sur des questions de haut niveau 00:16:25.760 --> 00:16:28.740 comme l'ergonomie, la fluidité des flux de travail et l'accessibilité. 00:16:29.440 --> 00:16:31.980 Des domaines qu'aucun moteur autonome ne peut évaluer de manière pertinente. 00:16:31.980 --> 00:16:35.020 Pour les professionnels souhaitant tâter le terrain, commencez petit. 00:16:35.960 --> 00:16:38.380 Exécutez un agent de test autonome sur un environnement de staging 00:16:38.380 --> 00:16:40.420 ou de pré-production pendant une période définie. 00:16:41.660 --> 00:16:44.000 Comparez la liste des problèmes découverts avec votre backlog actuel. 00:16:44.680 --> 00:16:46.300 Considérez cet exercice comme une collecte de données. 00:16:46.700 --> 00:16:48.280 Les nouvelles découvertes sont-elles réellement utiles ? 00:16:48.280 --> 00:16:49.840 Font-elles doublons avec les tests existants ? 00:16:49.840 --> 00:16:51.980 Révèlent-elles des angles morts importants pour votre entreprise ? 00:16:52.700 --> 00:16:54.720 Présenté ainsi, vous mesurez le retour sur investissement 00:16:54.720 --> 00:16:57.480 au lieu de miser la qualité de vos versions sur une technique non éprouvée. 00:16:58.060 --> 00:16:59.720 Et lorsque les équipes mènent ce genre de projet pilote, 00:17:00.160 --> 00:17:01.060 un modèle se dessine. 00:17:01.980 --> 00:17:04.540 Le véritable avantage à long terme ne réside pas seulement dans la détection de bugs, 00:17:04.540 --> 00:17:06.760 mais dans la rapidité avec laquelle ces leçons sont réintégrées 00:17:06.760 --> 00:17:08.060 dans le cycle de développement global. 00:17:09.380 --> 00:17:11.240 Chaque anomalie détectée, chaque idée consignée, 00:17:11.360 --> 00:17:13.780 représente un savoir qui ne devrait pas s'évaporer à la fin d'un sprint. 00:17:14.900 --> 00:17:17.100 La question est de savoir comment cette intelligence est stockée, 00:17:17.200 --> 00:17:18.220 partagée et transmise, 00:17:18.720 --> 00:17:21.220 pour éviter que les mêmes erreurs ne se répètent sous des noms de projets différents. 00:17:22.840 --> 00:17:24.300 Boucler la boucle d'intelligence dans DevOps. 00:17:24.700 --> 00:17:26.600 En DevOps, l'un des problèmes les plus difficiles à résoudre 00:17:26.600 --> 00:17:28.680 est la rapidité avec laquelle les connaissances s'estompent entre l'esprit. 00:17:29.560 --> 00:17:31.760 Les problèmes sont enregistrés, les post-mortem sont rédigés, 00:17:31.760 --> 00:17:32.980 mais au début du projet suivant, 00:17:33.140 --> 00:17:35.360 bon nombre de ces leçons ne sont pas réintégrées dans le flux de travail. 00:17:36.300 --> 00:17:39.580 Boucler la boucle de l'intelligence dans le DevOps consiste à mettre fin à ce cycle de pertes 00:17:39.580 --> 00:17:41.860 et à s'assurer que ce que les équipes apprennent améliorent réellement la suite. 00:17:42.940 --> 00:17:45.220 L'IA agentique soutient cette démarche en se connectant aux endroits 00:17:45.220 --> 00:17:46.540 où les connaissances circulent déjà. 00:17:47.280 --> 00:17:49.580 Le premier point d'intégration est l'ingestion des logs de la télémétrie. 00:17:49.580 --> 00:17:53.620 Au lieu de demander aux ingénieurs d'éplucher des tableaux de bord ou des incidents archivés, 00:17:53.800 --> 00:17:57.480 les agents analysent en continu les métriques, les taux d'erreur et les traces de performance 00:17:57.480 --> 00:17:59.580 reliant les anomalies entre les versions. 00:18:00.620 --> 00:18:03.200 Le second est l'analyse de l'historique des pull requests et des revues de code. 00:18:04.060 --> 00:18:06.920 Les décisions prises dans les commentaires contiennent souvent un contexte sur les compromis 00:18:06.920 --> 00:18:08.640 ou les risques et n'atteignent jamais la documentation. 00:18:09.740 --> 00:18:12.140 En traitant ces conversations, les agents préservent le pourquoi des choses 00:18:12.140 --> 00:18:13.340 et pas seulement ce qui a été fusionné. 00:18:13.340 --> 00:18:17.340 La troisième est la mise en correspondance des échecs observés avec des recommandations architecturales. 00:18:18.220 --> 00:18:20.980 Si certaines stratégies de mise en cache créent systématiquement une surcharge mémoire 00:18:20.980 --> 00:18:22.920 ou si des modèles de mise à l'échelle déclenchent des time-out, 00:18:23.040 --> 00:18:24.980 ces informations sont remontées lors de la planification 00:18:24.980 --> 00:18:26.980 avant que les mêmes erreurs ne se reproduisent. 00:18:28.220 --> 00:18:30.600 Ensemble, ces points d'intégration améliorent la mémoire institutionnelle 00:18:30.600 --> 00:18:31.620 sans promettre la perfection. 00:18:32.840 --> 00:18:35.280 La valeur n'est pas que les agents se souviennent parfaitement de chaque détail, 00:18:35.400 --> 00:18:36.080 mais qu'ils augmentent. 00:18:36.300 --> 00:18:38.660 Les chances que les leçons passées réapparaissent au bon moment. 00:18:39.340 --> 00:18:40.600 La supervision humaine reste indispensable. 00:18:40.600 --> 00:18:43.600 Les développeurs doivent valider la pertinence des idées soulevées 00:18:43.600 --> 00:18:46.280 et les organisations doivent planifier des audits réguliers 00:18:46.280 --> 00:18:47.180 de ce que capturent les agents 00:18:47.180 --> 00:18:50.060 pour éviter que des dérives ou du bruit ne s'infiltrent dans le système. 00:18:51.360 --> 00:18:54.340 Avec un examen attentif, l'intelligence devient exploitable plutôt que pesante. 00:18:55.080 --> 00:18:56.820 La gouvernance est un autre élément incontournable. 00:18:57.280 --> 00:18:59.660 L'alimentation d'un système d'agents, avec des logs, des pull requests 00:18:59.660 --> 00:19:01.780 et des résultats de déploiement, soulève des questions de confidentialité, 00:19:01.920 --> 00:19:04.180 de conservation et de conservation et de conformité. 00:19:04.180 --> 00:19:06.080 Tous les artefacts ne doivent pas durer éternellement 00:19:06.080 --> 00:19:08.340 et toutes les données ne doivent pas être accessibles à tous les rôles. 00:19:08.340 --> 00:19:10.960 Avant de déployer ce type de couche mémoire, 00:19:11.120 --> 00:19:12.780 les équipes doivent définir des limites claires 00:19:12.780 --> 00:19:15.460 de rétention des données, établir des politiques d'accès 00:19:15.460 --> 00:19:18.000 et s'assurer que les données sensibles sont nettoyées ou masquées. 00:19:19.220 --> 00:19:21.600 Sans ces limites, vous risquez de créer un dépôt fantôme 00:19:21.600 --> 00:19:23.220 incontrôlé de l'historique de l'entreprise 00:19:23.220 --> 00:19:25.040 qui complique les audits au lieu de les soutenir. 00:19:26.220 --> 00:19:27.540 Pour les développeurs, l'impact le plus notable 00:19:27.540 --> 00:19:28.840 se fait sentir lors du lancement d'un projet. 00:19:29.380 --> 00:19:31.360 Au lieu de vagues souvenirs de ce qui a mal tourné la dernière fois, 00:19:31.360 --> 00:19:34.360 des informations apparaissent directement dans le contexte. 00:19:34.540 --> 00:19:35.920 Lancez une nouvelle API WebDoneNet 00:19:35.920 --> 00:19:37.660 et le système pourrait vous suggérer, l'an dernier, 00:19:38.060 --> 00:19:40.800 cette bibliothèque de cache a causé des fuites de mémoire sous charge, 00:19:41.480 --> 00:19:42.260 envisager une alternative. 00:19:42.680 --> 00:19:44.220 Ou lors de la planification, il pourrait signaler 00:19:44.220 --> 00:19:46.480 que certains modèles d'injection de dépendance ont créé de l'instabilité. 00:19:48.240 --> 00:19:50.020 Ces rappels sont opportuns par rétrospectif, 00:19:50.120 --> 00:19:52.700 ils permettent donc de passer d'une réaction au problème à leur prévention. 00:19:53.620 --> 00:19:55.280 C'est ainsi que l'intelligence du projet s'accumule 00:19:55.280 --> 00:19:56.960 au lieu de se réinitialiser à chaque début de sprint. 00:19:57.820 --> 00:19:59.440 Cela modifie également la nature des rétrospectives. 00:20:00.140 --> 00:20:02.580 Les rétrospectives classiques recueillent des retours à un instant T 00:20:02.580 --> 00:20:03.240 et puis passent à autre chose. 00:20:04.060 --> 00:20:05.080 Avec des agents dans la boucle, 00:20:05.500 --> 00:20:06.840 ces connaissances ne sont pas mises de côté, 00:20:07.340 --> 00:20:09.540 elles sont continuellement réintégrées dans le cycle de développement. 00:20:10.640 --> 00:20:11.500 Les journaux de ce mois-ci, 00:20:11.920 --> 00:20:13.680 les anomalies de mise à l'échelle du dernier trimestre 00:20:13.680 --> 00:20:15.560 ou les régressions de performance notées il y a deux ans 00:20:15.560 --> 00:20:17.140 alimentent les recommandations d'aujourd'hui. 00:20:18.360 --> 00:20:20.840 En faisant de chaque version une partie d'une boucle d'apprentissage continue, 00:20:21.000 --> 00:20:23.440 les équipes réduisent le risque de voir ressurgir des erreurs déjà vécues. 00:20:24.360 --> 00:20:26.240 Pourtant, les résultats doivent être mesurés, pas supposés. 00:20:26.740 --> 00:20:28.840 Une première étape simple consiste à intégrer l'agent 00:20:28.840 --> 00:20:29.880 à une source de télémétrie unique, 00:20:30.000 --> 00:20:31.420 comme les journaux d'application ou un flux APM 00:20:31.420 --> 00:20:32.700 et de l'exécuter pendant deux sprints. 00:20:33.340 --> 00:20:34.900 Comparé ensuite, l'agent a-t-il mis en évidence 00:20:34.900 --> 00:20:36.580 des modèles que vous n'aviez pas repérés ? 00:20:36.580 --> 00:20:38.120 Ces modèles ont-ils conduit à de réels changements 00:20:38.120 --> 00:20:39.560 dans le code ou l'infrastructure ? 00:20:39.560 --> 00:20:42.440 Et la qualité des versions s'est-elle améliorée de manière mesurable ? 00:20:42.440 --> 00:20:43.200 Si la réponse est oui, 00:20:43.360 --> 00:20:44.760 alors étendre aux historiques de PR 00:20:44.760 --> 00:20:46.340 ou au mappage architectural est pertinent. 00:20:47.200 --> 00:20:48.520 Sinon, l'expérience révèle elle-même 00:20:48.520 --> 00:20:49.340 ce qui doit être ajustée, 00:20:49.420 --> 00:20:50.700 que ce soit au niveau des sources de données, 00:20:50.980 --> 00:20:52.860 de la gouvernance ou des processus de revue. 00:20:53.780 --> 00:20:55.320 Avec le temps, le bénéfice est cumulatif. 00:20:55.780 --> 00:20:57.280 En améliorant la mémoire institutionnelle, 00:20:57.360 --> 00:20:58.760 la vélocité des versions se stabilise, 00:20:58.960 --> 00:21:00.340 l'architecture devient plus résiliente 00:21:00.340 --> 00:21:02.080 et l'énergie technique est moins gaspillée 00:21:02.080 --> 00:21:04.240 à redécouvrir d'anciens pièges. 00:21:05.700 --> 00:21:07.640 La connaissance ne passe plus entre les mailles du filet 00:21:07.640 --> 00:21:09.820 et s'accumule en tant que ressource fiable pour les équipes. 00:21:10.580 --> 00:21:12.560 A ce stade, le rôle de liage antique change de perspective. 00:21:13.180 --> 00:21:14.860 Ce n'est plus seulement un assistant à une étape du développement. 00:21:15.260 --> 00:21:16.860 Il commence à tisser l'ensemble du processus 00:21:16.860 --> 00:21:18.060 en transmettant les leçons apprises 00:21:18.060 --> 00:21:19.280 plutôt que de les laisser expirer. 00:21:20.740 --> 00:21:22.340 Cette continuité transforme le DevOps 00:21:22.340 --> 00:21:23.840 passant d'un ensemble de tâches isolées 00:21:23.840 --> 00:21:24.980 à un cycle de vie connecté, 00:21:25.080 --> 00:21:26.720 préparant le terrain pour le changement plus large 00:21:26.720 --> 00:21:28.240 qui s'opère dans les équipes logicielles. 00:21:30.040 --> 00:21:31.840 L'IA agentique marque un tournant pragmatique 00:21:31.840 --> 00:21:32.360 dans le développement. 00:21:33.600 --> 00:21:35.140 Concept, ce n'est pas un assistant de code, 00:21:35.340 --> 00:21:36.660 mais un système qui transporte la mémoire, 00:21:36.780 --> 00:21:37.840 le contexte et les objectifs 00:21:37.840 --> 00:21:38.700 tout au long du cycle de vie. 00:21:39.820 --> 00:21:41.140 Application, les points d'entrée les plus clairs 00:21:41.140 --> 00:21:42.180 pour les équipes Donnet et Azure 00:21:42.180 --> 00:21:43.380 sont la création de nouveaux projets, 00:21:43.500 --> 00:21:45.100 la gestion du provisionnement courant par les agents 00:21:45.100 --> 00:21:47.400 et l'expérimentation de la génération de tests automatisés. 00:21:48.900 --> 00:21:51.640 Impact, bien mené, cela rationalise les flux de travail, 00:21:51.640 --> 00:21:52.880 réduit la charge de configuration 00:21:52.880 --> 00:21:54.560 et diminue le risque de répétition d'erreurs 00:21:54.560 --> 00:21:55.860 déjà rencontrées sur d'autres co-projets. 00:21:56.400 --> 00:21:57.440 La meilleure prochaine étape 00:21:57.440 --> 00:21:59.040 est de le tester dans votre propre environnement. 00:21:59.560 --> 00:22:01.400 Essayez d'activer Copilot sur un petit prototype 00:22:01.400 --> 00:22:03.160 ou lancer un agent sur votre environnement de staging, 00:22:03.380 --> 00:22:04.360 puis suivez un indicateur, 00:22:04.600 --> 00:22:06.280 temps gagné, bug découvert ou dérives évités. 00:22:07.060 --> 00:22:08.720 Si vous rencontrez un problème DevOps récurrent 00:22:08.720 --> 00:22:09.720 qui ralentit votre équipe, 00:22:10.080 --> 00:22:10.960 partagez-le en commentaire 00:22:10.960 --> 00:22:11.880 pour que les autres puissent comparer. 00:22:12.700 --> 00:22:14.080 Si vous souhaitez des conseils plus concrets 00:22:14.080 --> 00:22:15.760 sur Donnet, Azure et l'adoption de l'IA, 00:22:15.960 --> 00:22:17.320 abonnez-vous pour nos prochaines analyses. 00:22:17.320 --> 00:22:19.500 Les gains semblent minimaux au début, 00:22:19.640 --> 00:22:21.000 mais ils se cumulent grâce à la gouvernance 00:22:21.000 --> 00:22:22.520 au suivi et à une itération constante.