Latest / M365.FM – Podcast Microsoft 365, Copilot & IA en français / Passer de Java 8 à Java 21 avec des agents IA : mise à niveau, CVE corrigées et migration d'AWS vers Azure (Doublage IA)

Transcript

Passer de Java 8 à Java 21 avec des agents IA : mise à niveau, CVE corrigées et migration d'AWS vers Azure (Doublage IA) · M365.FM – Podcast Microsoft 365, Copilot & IA en français

0:00
Speaker 2: mettez encore à jour manuellement du jeu à vérité. Ce
0:01
Speaker 2: n'est pas de l'artisanat, c'est de la pénitence non rémunérée.
0:04
Speaker 2: La modernisation manuelle est un mode d'échec lent, sujet aux
0:06
Speaker 2: erreurs et perpétuellement en retard. Vérité. Les agents IA gèrent
0:09
Speaker 2: désormais les tâches ingrates, preuve à l'appui. Voici ce que
0:12
Speaker 2: vous y gagnez réellement. Du temps, la fin des CVE
0:15
Speaker 2: et des factures cloud qui cessent de s'envoler. Nous allons
0:17
Speaker 2: étudier une étude de cas, des benchmarks de stack, des
0:19
Speaker 2: résultats et une piste d'audit complète pour assurer la gouvernance.
0:23
Speaker 2: Il y a une métrique qui a embarrassé la finance
0:24
Speaker 2: et ravi la sécurité. Restez pour voir ça. Voici ce
0:27
Speaker 2: qui arrive quand vous laissez Copilot piloter la modernisation de
0:29
Speaker 2: vos applications. Le contexte, la stack héritée et le mandat
0:32
Speaker 2: de modernisation. Commençons par la base, une application Spring de
0:36
Speaker 2: l'ère Java 8 MVC classique, avec quelques tâches planifiées, construites
0:39
Speaker 2: avec Maven et tournant sur AWS, AWS. Gouvernance conservatrice, à
0:44
Speaker 2: l'air bruyante, tout le monde jure que l'app est stable,
0:46
Speaker 2: alors que PagerDuty dit le contraire. La stack dérive, les
0:50
Speaker 2: POM par an ont été forqués il y a des années,
0:51
Speaker 2: les versions de dépendance sont épinglées comme des insectes, et
0:54
Speaker 2: un pipeline CI qui ne passe que si l'on prie.
0:57
Speaker 2: Comportement utilisateur classique. Ignorer les badges rouges, faire taire le
1:00
Speaker 2: scanner et prier pour que le prochain sprint inclue la
1:02
Speaker 2: dette technique. Spoiler, ça n'arrive jamais. Inventaire des problèmes. La
1:07
Speaker 2: délivre des versions signifie que les bibliothèques modernes ne se
1:09
Speaker 2: résolvent pas sans exclusion. L'enfer des dépendances. La roulette transitive
1:13
Speaker 2: ou une mise à jour de log fait exploser votre
1:15
Speaker 2: client HTTP. Les CVE non corrigés attendent poliment un kit d'exploitation.
1:20
Speaker 2: Gaspillage de ressources, autoscaling qui ne réduit jamais. Instance à
1:23
Speaker 2: 8% des CPU pendant que la finance finance un chauffage d'appoint. Point.
1:27
Speaker 2: Ajouter des configs fragiles, des variables d'environnement dans les données utilisateurs,
1:30
Speaker 2: des écritures sur disque avec état et des secrets stockés
1:32
Speaker 2: là où ils ne devraient pas être. Contraintes? Ceci est
1:35
Speaker 2: uniquement audio. Pas d'héroïsme de façade, pas de basculement d'onglet.
1:38
Speaker 2: Vers stack overflow. Nous nous basons sur des artefacts reproductibles,
1:42
Speaker 2: des rapports, des diffs de commits et des sorties de
1:44
Speaker 2: scanners car deviner n'est pas une stratégie et qu'est-ce qui
1:46
Speaker 2: marche sur ma machine preuve. Pourquoi Java 21? Les threads
1:49
Speaker 2: virtuels transforment la concurrence d'une ressource rare, elle devient une commodité.
1:52
Speaker 2: Des milliers de threads légers avec un surcoût minimal, le
1:55
Speaker 2: débit augmente. La latence de queue diminue. Amélioration du garbage collector,
1:59
Speaker 2: les raffinements de G1 et ZGC réduisent les temps de pause.
2:03
Speaker 2: L'API pour les fonctions et la mémoire étrangère est stable,
2:05
Speaker 2: ce qui compte si vous appelez du code natif ou
2:06
Speaker 2: gérez des buffers ORIP. Effets nets et des gains mesurables
2:10
Speaker 2: en performance et maintenabilité. La plupart des gens pensent que
2:12
Speaker 2: la mise à jour est cosmétique, c'est faux! Vous obtenez
2:14
Speaker 2: une concurrence moins coûteuse et moins de blocage, directement visible
2:17
Speaker 2: dans les graphiques de niveau de service. Périmètre de migration,
2:20
Speaker 2: sortir d'AWS, entrer sur Azure, s'aligner sur les standards d'entreprise,
2:22
Speaker 2: consolider la facturation et s'intégrer à la plateforme où réside
2:25
Speaker 2: déjà votre identité, vos politiques et votre observabilité. Nous ciblerons
2:28
Speaker 2: Azure App Service ou Azure Spring Apps selon le profil
2:30
Speaker 2: de la charge de travail. Application simple, App Service suffit.
2:34
Speaker 2: Microservices lourds sous Spring, avec scalabilité complexe, pensez à Azure
2:37
Speaker 2: Spring Apps. Pour les données, la directive est Azure SQL Database. Oui,
2:42
Speaker 2: vous pouvez garder PostgreSQL sur Azure, mais l'entreprise veut consolider,
2:44
Speaker 2: donc nous tracerons la voie et montrerons les compromis. Position
2:47
Speaker 2: sur la gouvernance. Chaque action finit dans Git. Diffable, réversible, attribuable.
2:54
Speaker 2: L'agent génère un plan, ouvre des tickets et propose des commits.
2:57
Speaker 2: Vous approuvez. Il résout les bills, corrige les dépendances, applique
3:00
Speaker 2: des transformations de code via des recettes connues, régénère le
3:03
Speaker 2: SBOAM et relance les... scanners... Si quelque chose échoue, il boucle.
3:08
Speaker 2: Fini le pèlerinage Altab. Et quand il ne peut pas avancer,
3:10
Speaker 2: il demande une intervention et documente pourquoi. Voyez la différence.
3:13
Speaker 2: Le travail devient auditable au lieu d'anecdotique. Avant de laisser
3:16
Speaker 2: un agent toucher à quoi que ce soit, vous évaluez.
3:19
Speaker 2: Inventaire automatisé des modules, dépendance, plugin de build et config d'exécution.
3:24
Speaker 2: Résultats classés par risque avec référence aux avis et à
3:26
Speaker 2: la documentation. Indicateur de préparation au cloud pour les liaisons
3:30
Speaker 2: de services, variables d'environnement et pièges avec état qui rompent
3:32
Speaker 2: lors du cycle de vie des conteneurs. Base de coût,
3:35
Speaker 2: heure de calcul, taux d'inactivité et modèle de sortie réseau
3:37
Speaker 2: que la finance feint d'ignorer jusqu'à la fin du mois.
3:40
Speaker 2: Vous vous dites peut-être, nous pouvons trier cela à la main. Fascinant,
3:43
Speaker 2: et vous vous étonnez encore que l'app plante. L'utilisateur moyen
3:47
Speaker 2: rate les problèmes de fonds. les API obsolètes au cœur
3:49
Speaker 2: du planificateur, un pont de journalisation masquant des conflits de classe,
3:53
Speaker 2: ou cette bibliothèque bloquante. L'agent ne les rate pas, car
3:57
Speaker 2: il ne s'ennuie jamais. Donc, le mandat de modernisation est
4:00
Speaker 2: simple et définitif. Passer à Java 21, éliminer les CVE, containeriser,
4:04
Speaker 2: migrer vers Azure via CICD avec déploiement contrôlé, imposer des
4:07
Speaker 2: politiques via approbation équivolte et réduire les coûts sans sacrifier
4:10
Speaker 2: la fiabilité. Tous les changements sont tracés par des commits
4:14
Speaker 2: avec justification. Pas de boîte noire. Pas de commis de
4:17
Speaker 2: héros à 2h du matin. L'évaluation d'abord, car deviner n'est
4:20
Speaker 2: pas une stratégie. Puis, on exécute. Évaluation. L'IA expose la
4:24
Speaker 2: dette technique avec preuve à l'appui. Voici ce qui se
4:27
Speaker 2: passe réellement quand vous appuyez sur eBay. L'agent ne scanne pas.
4:30
Speaker 2: Il inventorie. Code, fichier de build, plugin, dépendance transitive, éléments Docker,
4:36
Speaker 2: variables d'environnement, scripts de démarrage. Même ce vieux rappeur Shell
4:40
Speaker 2: copié en 2017. Il construit un graphe de dépendance, la
4:44
Speaker 2: note avec les données CVE et classe les risques. Pas
4:46
Speaker 2: au feeling. C'est vérité, exploitabilité, accessibilité, accessibilité. C'est le registre
4:50
Speaker 2: Windows de la réalité de votre application. Pas juste une liste,
4:53
Speaker 2: votre structure dorsale mise à nu. La vérité, la plupart
4:56
Speaker 2: des gens pensent connaître leur stack. Ils ne la connaissent pas.
4:59
Speaker 2: L'agent trouve le POM, pas renforqué avec une version figée
5:01
Speaker 2: qui bloque tous les correctifs en aval. Il signale les
5:04
Speaker 2: points SLF4I en double qui se chevauchent comme des colocataires
5:06
Speaker 2: en conflit. Il détecte le conteneur de servlet discrètement obsolète
5:09
Speaker 2: de trois versions car votre CI ne teste que le
5:11
Speaker 2: scénario idéal. Eh oui, cartographie des API obsolètes que vous
5:15
Speaker 2: utilisez depuis des années parce que personne ne voulait toucher
5:16
Speaker 2: au planificateur de tâches. Spoiler, vous allez y toucher maintenant. Ensuite,
5:20
Speaker 2: les CVE. Analyse de la sévérité, bibliothèque affectée et référence
5:23
Speaker 2: aux avis de sécurité. Des liens directs, pas des rumeurs.
5:25
Speaker 2: Les vulnérabilités critiques et élevées sont prioritaires, mais identifiez aussi
5:28
Speaker 2: si les chemins de code vulnérables sont accessibles par votre application.
5:31
Speaker 2: L'accessibilité compte. Si une bibliothèque transitive a un problème, mais
5:35
Speaker 2: que votre code n'appelle jamais la classe vulnérable, elle est signalée,
5:38
Speaker 2: mais l'agent priorise les correctifs réduisant les risques réels. Vous
5:42
Speaker 2: obtenez les options de remédiation. Mettre à jour les versions,
5:44
Speaker 2: ajouter des exclusions ou remplacer complètement les artefacts, c'est un menu,
5:47
Speaker 2: pas un mystère. La préparation à la mise à niveau
5:49
Speaker 2: est justifiée par des... Java 21 exige que vous cessiez
5:51
Speaker 2: de faire comme si nous étions en 2009. L'agent exécute
5:54
Speaker 2: des recettes Open Rewrite sur votre base de code en
5:56
Speaker 2: mode simulation, montrant précisément quelles API sont obsolètes, quels imports
5:59
Speaker 2: changés et où se cachent les changements de comportement. Il
6:02
Speaker 2: souligne les accès réflexifs illégaux, les bizarreries de JUC et
6:05
Speaker 2: les petites mines prêtes à exploser dans la configuration XML.
6:08
Speaker 2: Il note les frameworks prêts, les versions de Spring, la
6:10
Speaker 2: compatibilité des plugins et ceux qui nécessitent une adaptation, pas
6:13
Speaker 2: de blabla. Chaque changement proposé renvoie vers la documentation et
6:16
Speaker 2: les notes de migration. La préparation au cloud est l'endroit
6:18
Speaker 2: où les caractéristiques de votre infrastructure sont cataloguées. L'agent identifie
6:21
Speaker 2: les pièges liés à l'état, comme l'écriture de fichiers temporaires
6:24
Speaker 2: sur le disque local, le cache de sessions en mémoire
6:26
Speaker 2: entre les instances ou le stockage de secrets dans un
6:29
Speaker 2: fichier texte dans Opt. Il signale l'utilisation de variables d'environnement
6:34
Speaker 2: basées sur des modèles de métadonnées EC2. Il pointe les
6:37
Speaker 2: liaisons de service pour les files d'attente redis et les
6:39
Speaker 2: bases de données qui ne survivront pas au cycle de
6:40
Speaker 2: vie des contenants. Puis il propose des liaisons à la
6:42
Speaker 2: manière d'Azure. Les chaînes de connexion passent à la configuration
6:45
Speaker 2: qui volte pour les secrets, identité gérée pour l'authentification. Vous savez,
6:48
Speaker 2: comme des adultes. Passons maintenant aux chocs financiers, les bases
6:51
Speaker 2: de coût. L'agent extrait les heures de calcul, les tailles d'instance,
6:54
Speaker 2: les modèles de mise à l'échelle et les taux d'inactivité
6:55
Speaker 2: depuis la télémétrie et l'infrastructure. Il estime les coûts de
6:58
Speaker 2: sortie de données basés sur les modèles sortants. Oui, ce
7:01
Speaker 2: job par l'eau bruyant qui transfère des données entre régions
7:03
Speaker 2: chaque nuit à droit à sa ligne. Il traduit tout
7:06
Speaker 2: cela en un chiffre mensuel qui se moque de vos anecdotes.
7:09
Speaker 2: C'est le chiffre qui a embarrassé la finance et ravi
7:11
Speaker 2: la sécurité. Parce qu'éliminer les CVE tout en réduisant les
7:14
Speaker 2: dépenses est la seule religion que partagent ces deux équipes.
7:17
Speaker 2: Des preuves où ça n'existe pas. L'agent génère un fichier
7:20
Speaker 2: de plan avec des sections, les étapes de remédiation CVE,
7:23
Speaker 2: les recettes de mise à niveau Java, les changements de build,
7:25
Speaker 2: les transformations de code, la containerisation et les mappages de
7:28
Speaker 2: cibles cloud. Il ouvre des tickets par flux de travail,
7:31
Speaker 2: identifie les responsables si vous le souhaitez et prépare les
7:33
Speaker 2: commis dans une branche séparée. Des diffs propres et réduits
7:36
Speaker 2: avec les justifications dans les messages. SBOM généré, signé et versionné.
7:40
Speaker 2: Sorti du scanner de vulnérabilité jointe. C'est prêt pour l'audit
7:42
Speaker 2: de la première étape. Vous voulez la traçabilité? Chaque constat
7:45
Speaker 2: est lié à un avis ou à un document de référence.
7:48
Speaker 2: Entrée NVD, note de version de projet, documentation Open Rewrite,
7:51
Speaker 2: guide de migration Azure. Lorsqu'il suggère de remplacer une bibliothèque,
7:55
Speaker 2: il cite les matrices de compatibilité. Lorsqu'il recommande de déplacer
7:58
Speaker 2: un secret, il pointe vers les conseils de la plateforme
8:00
Speaker 2: sur Key Vault et les identités gérées. Ce n'est pas
8:02
Speaker 2: juste parce que l'IA le dit, c'est parce que cette
8:04
Speaker 2: norme précise, l'exige, l'exige. Le contrôle reste humain. Le plan
8:09
Speaker 2: est dans Git en attente d'approbation. Vous pouvez ajuster les priorités,
8:12
Speaker 2: rejeter une stratégie de remédiation ou demander un service cible
8:15
Speaker 2: différent Azure App Service plutôt qu'Azure Spring Apps avec les
8:17
Speaker 2: compromis clairement listés. L'agent s'adapte, relance l'évaluation des écarts et
8:22
Speaker 2: met à jour les artefacts. Sans rancune. Une fois l'épreuve
8:25
Speaker 2: sous les yeux, la posture change. Vous arrêtez de débattre
8:28
Speaker 2: de l'utilité de la modernisation pour commencer à planifier le travail.
8:31
Speaker 2: Et oui, l'utilisateur lambda essaiera toujours de livrer une fonctionnalité
8:34
Speaker 2: en priorité. Fascinant. Pendant ce temps, l'agent a déjà tracé
8:37
Speaker 2: le chemin le plus court vers un environnement d'exécution sécurisé,
8:39
Speaker 2: conforme et moins complexe. Approuvez le plan, puis regardez-le faire
8:41
Speaker 2: le travail que vous ne cessez de reporter. Mise à
8:43
Speaker 2: niveau automatisé Java 8 vers Java 21, sans le moindre drame. Drame.
8:47
Speaker 2: Plan approuvé, l'agent arrête de parler et passe à l'action.
8:50
Speaker 2: La boucle est simple et impitoyable. Appliquer la recette, construire, tester, corriger.
8:54
Speaker 2: Répéter jusqu'à obtenir le feu. Pas d'explosion de dépôt, pas
8:57
Speaker 2: d'archéologie sur les forums, pas de tentative de réinstallation propre.
9:00
Speaker 2: Il utilise des recettes Open Rewrite pour réécrire les API,
9:03
Speaker 2: des Maven Enforcer pour normaliser les versions et une suite
9:05
Speaker 2: de tests d'intégration pour prouver qu'il n'a rien cassé. Quand
9:09
Speaker 2: une construction échoue, il ne panique pas. Il segmente l'échec,
9:12
Speaker 2: propose un changement ciblé et relance. La discipline à la
9:15
Speaker 2: vitesse de la machine. Les mises à jour des dépendances
9:17
Speaker 2: sont le domaine où les humains créent habituellement le chaos.
9:19
Speaker 2: Place à l'alignement BOM. L'agent adopte la nomenclature officielle pour
9:22
Speaker 2: Spring et les écosystèmes liés centralisent les versions et suppriment
9:25
Speaker 2: la dispersion des versions dans les POM enfants. Il restreint
9:29
Speaker 2: les plages de versions à des contraintes exactes ou gérées.
9:31
Speaker 2: Pour éviter la roulette transitive, supprime les exclusions redondantes et
9:33
Speaker 2: ajoute l'exclusion cruciale en cas de conflit entre deux back-ends
9:36
Speaker 2: de journalisation. Résultat? Moins de surprises, moins de conflits de jarres,
9:40
Speaker 2: moins d'alertes nocturnes, voyez la stabilité. Maintenant le code. Java
9:44
Speaker 2: 21 signifie que vos anciennes API ont besoin d'une surveillance adaptée.
9:47
Speaker 2: L'agent remplace les classes et méthodes obsolètes par des équivalents supportés,
9:50
Speaker 2: met à jour les imports et ajuste les signatures de
9:52
Speaker 2: méthodes selon l'évolution de la plateforme. Il propose des refactorisations optionnelles,
9:56
Speaker 2: l'utilisation de records et de patterns, ainsi que des collections
9:59
Speaker 2: séquencées via un indicateur. de fonctionnalité pour minimiser les diffs.
10:02
Speaker 2: Il résout aussi les accès réflexifs illégaux en les remplaçant
10:04
Speaker 2: par des alternatives supportées par le SBI ou le JDK,
10:07
Speaker 2: puis annote le commit avec une brève justification et des
10:09
Speaker 2: liens vers les notes de migration. Ce n'est pas juste
10:12
Speaker 2: un correctif, c'est une preuve. La correction de sécurité n'est
10:15
Speaker 2: pas un ajout de dernière minute, elle est intégrée À
10:17
Speaker 2: mesure que les dépendances évoluent, l'agent vérifie à nouveau les CVE,
10:20
Speaker 2: book sur les résultats résiduels et régénère la nomenclature logicielle
10:23
Speaker 2: S-BOMB pour que vos scanners voient la réalité actuelle et
10:25
Speaker 2: non un souvenir. Et oui, il exécute le scanner de
10:27
Speaker 2: vulnérabilité et bloque la build en cas de régression. Vous
10:30
Speaker 2: avez dit que c'était strict. Exact. Sécurité appelle ça le
10:32
Speaker 2: professionnalisme minimum viable. Parlons des tests, car l'utilisateur moyen adore
10:36
Speaker 2: dire« ça compile, ça compile». Comme si c'était un exploit.
10:39
Speaker 2: L'agent exécute vos tests unitaires, vos tests d'intégration et, si
10:42
Speaker 2: vous les avez configurés, vos tests de contrat sur des
10:44
Speaker 2: services factices. Si les tests sont fragiles, il crée des
10:46
Speaker 2: tickets avec un résultat d'échec précis et des correctifs recommandés.
10:49
Speaker 2: Si un test instable bloque la progression, il propose de
10:52
Speaker 2: le mettre en quarantaine avec un tag, documente le risque
10:54
Speaker 2: et poursuit sur les zones non risquées, de l'élan sans déni.
10:58
Speaker 2: Passons au benchmark. Une fois la mise à niveau stabilisée,
11:01
Speaker 2: l'agent exécute des tests ciblés de débit et de latent
11:03
Speaker 2: sur les mêmes charges de travail que la base de référence.
11:06
Speaker 2: L'impact est là où Java 21 justifie son existence. Plus
11:09
Speaker 2: de requêtes simultanées pour le même budget CPU grâce aux
11:11
Speaker 2: trades virtuels, une latence de queue plus faible grâce aux
11:13
Speaker 2: améliorations du GC et moins de pénalités de changement de contexte.
11:17
Speaker 2: Pas besoin d'adorer les benchmarks pour comprendre des graphiques qui
11:19
Speaker 2: penchent dans la bonne direction. Le rapport précise quelles améliorations
11:22
Speaker 2: proviennent des trades virtuels ou des réglages du GC, afin
11:24
Speaker 2: que vous puissiez créditer la bonne fonctionnalité quand la finance
11:27
Speaker 2: demande pourquoi les machines sont soudainement moins inactives. L'hygiène des
11:31
Speaker 2: builds est importante. L'agent normalise les wrappers Maven, fixe la
11:34
Speaker 2: chaîne d'outils sur une distribution Java 21 que vous contrôlez réellement,
11:37
Speaker 2: et supprime les plugins obsolètes qui ne servent qu'à ralentir
11:40
Speaker 2: les builds. Ils standardisent les drapeaux du compilateur, transforment les
11:44
Speaker 2: avertissements en erreur pour les modules approuvés et ajoutent une
11:47
Speaker 2: analyse statique là où le signal est fort. L'objectif n'est
11:50
Speaker 2: pas la perfection. L'objectif est la répétabilité et la banalité,
11:52
Speaker 2: le standard absolu pour les builds. C'est ici que les
11:55
Speaker 2: heures économisées apparaissent. Historiquement, ce genre de mise à niveau
11:58
Speaker 2: consomme des semaines de travail d'ingénieur senior à traquer des
12:01
Speaker 2: conflits transitifs, résoudre des échecs de plugins obscurs et gérer
12:03
Speaker 2: des tests instables. L'agent compresse cela en quelques jours. Non
12:07
Speaker 2: par magie, mais parce qu'ils ne se fatiguent pas, ne
12:08
Speaker 2: se laissent pas distraire et n'inventent pas de tâches inutiles.
12:12
Speaker 2: Vos humains consacrent leur temps à examiner les diffs et
12:14
Speaker 2: à prendre des décisions, pas à se deviner des numéros
12:15
Speaker 2: de version, pas... Et lorsque la boue converge, que la
12:18
Speaker 2: recette est appliquée, les builds au vert, les tests réussis
12:20
Speaker 2: et le scanner silencieux, vous obtenez une branche propre avec
12:22
Speaker 2: des commits petits et bien étiquetés. Chaque message précise le changement,
12:25
Speaker 2: sa raison d'être et sa source. Les retours en arrière
12:28
Speaker 2: sont évidents. Les approbations sont rapides. Les auditeurs peuvent les
12:30
Speaker 2: lire sans avoir à vous appeler. De plus, votre page
12:32
Speaker 2: reste silencieuse, ce qui prouve que la modernisation a eu lieu,
12:34
Speaker 2: et non une simple simulation. Runtime moderne sécurisé. L'application est
12:37
Speaker 2: plus rapide, plus sûre et franchement plus mature. Maintenant, la
12:39
Speaker 2: facture cloud et la topologie ont besoin d'être révisées. Migration cloud,
12:43
Speaker 2: départ de WS, arrivée sur Azure avec pipelines et politiques.
12:46
Speaker 2: Tout change lorsque l'environnement d'exécution est sain. Maintenant, nous déplaçons
12:49
Speaker 2: les meubles. Architecture cible d'abord, car une migration hasardeuse crée
12:51
Speaker 2: des pannes imprévisibles. Pour une application Spring MVC unique qui
12:54
Speaker 2: ne cherche pas à imiter un service mesh, Azure App
12:56
Speaker 2: Service est le chemin le plus efficace. Déploiement simple, mise
12:59
Speaker 2: à l'échelle intégrée et pas de Kubernetes surprise. Si vous
13:02
Speaker 2: avez plusieurs microservices Spring, de la découverte de services et
13:04
Speaker 2: des changements de configuration, Azure Spring Apps se rentabilise avec
13:06
Speaker 2: des composants Spring gérés et du déploiement bleu slash vert natif.
13:09
Speaker 2: L'agent ne devine pas. Il évalue la charge de travail
13:11
Speaker 2: selon les fonctionnalités, l'état et le trafic, puis recommande une
13:13
Speaker 2: solution avec des compromis et des notes sur les coûts.
13:15
Speaker 2: Vous approuvez. Procède. Les données suivent, et c'est là que
13:17
Speaker 2: les professionnels se distinguent des amateurs. La directive est Azure
13:20
Speaker 2: SQL Database. Oui, j'ai entendu votre nostalgie pour PostgreSQL. La
13:23
Speaker 2: gouvernance veut une consolidation, l'identité veut une authentification gérée et
13:26
Speaker 2: la finance veut une facture unique. L'agent invente au réutilisation
13:29
Speaker 2: JDBC les poules de connexion et les hypothèses des drivers.
13:32
Speaker 2: Il remplace le driver, met à jour l'URL JDBC, ajoute
13:35
Speaker 2: une logique de réessai pour les erreurs transitoires et traite
13:37
Speaker 2: les différences NCSQL, là où vous aviez écrit des requêtes spécifiques.
13:41
Speaker 2: Si la friction de migration est élevée, il propose une
13:43
Speaker 2: zone d'atterrissage intermédiaire sur Azure Database for PostgreSQL avec un
13:46
Speaker 2: plan de basculement futur et des délais clairement définis. Des
13:51
Speaker 2: options avec des preuves à l'appui? La conteneurisation n'est pas
13:54
Speaker 2: un trait de caractère, c'est un outil de répétabilité. L'agent
13:57
Speaker 2: génère un fichier Docker qui construit réellement une image de
13:59
Speaker 2: base minimale multi-étapes, un utilisateur non-route et des vérifications d'état.
14:03
Speaker 2: Il intègre des drapeaux JVM alignés sur Java 21 et
14:05
Speaker 2: votre budget mémoire, pas une copie aléatoire trouvée sur un blog. Ensuite,
14:09
Speaker 2: il émet l'infrastructure sous forme de code, Bicep ou modèle ARM,
14:11
Speaker 2: pour provisionner App Service ou Azure Spring Apps, les plans
14:14
Speaker 2: App Service, Key Vault, les identités et le réseau. Une
14:17
Speaker 2: définition d'environnement par étapes, dev, test, prod, même structure, taille différente.
14:22
Speaker 2: Moins de panne-surprise car la machine a cessé d'improviser. CICD
14:26
Speaker 2: est là où le mythe du hacka on déplorera plus
14:27
Speaker 2: tard vient mourir. Place à GitHub Actions? L'agent structure des
14:31
Speaker 2: workflows qui compile avec la chaîne d'outils Java 21 figé,
14:33
Speaker 2: exécute des tests et des scanners, construisent et scannent des
14:36
Speaker 2: images de conteneurs, puis déploient via des environnements nécessitant des approbations.
14:40
Speaker 2: Les retours en arrière sont un bouton, pas une service
14:41
Speaker 2: de spiritisme. Tac d'images précédents, slots précédents, modèles précédents. Il
14:45
Speaker 2: orchestre des tests de fumée après déploiement et conditionne la
14:47
Speaker 2: promotion à leur réussite. Vous ne comptez pas sur la
14:49
Speaker 2: chance pour que la prod ressemble au test, le pipeline l'impose.
14:52
Speaker 2: Les secrets ne sont pas des variables d'environnement en texte clair,
14:54
Speaker 2: ils résident dans KeyVault. L'agent provisionne les coffres, crée les
14:57
Speaker 2: références et fait passer l'application en identité managée. Cela signifie
15:00
Speaker 2: pas de clé intégrée, pas de commis de configuration accidentelle
15:03
Speaker 2: et pas de rotation nocturne parce que quelqu'un a divulgué
15:05
Speaker 2: des identifiants dans une capture d'écran. Il ajoute également des approbations. Conditionnel,
15:09
Speaker 2: les revues de sécurité surviennent quand la S-BOM change, les
15:11
Speaker 2: revues de coût quand les plans augmentent et le mode
15:13
Speaker 2: dégradé est verrouillé en cas de dérogation. Des garde-fous sans
15:17
Speaker 2: friction et les responsables gardent des traces. La réduction des
15:19
Speaker 2: coûts n'est pas une prière, c'est de l'architecture couplée à
15:21
Speaker 2: une politique. L'agent ajuste la taille des plans selon la
15:24
Speaker 2: mesure réelle du CPU et de la mémoire, pas selon
15:25
Speaker 2: les goûts. Pour le non-production, il recommande le passage à
15:28
Speaker 2: zéro des options de type consommation lorsque c'est possible. Pour
15:31
Speaker 2: la production, il définit des règles d'autoscaling basées sur des
15:33
Speaker 2: signaux réels, requêtes par seconde, CPU, profondeur de fail, et
15:37
Speaker 2: plafonne le nombre d'instances avec un processus d'exception documenté. L'entrée
15:41
Speaker 2: est optimisée en colocalisant les services et en redirigeant les
15:43
Speaker 2: tâches nocturnes bavardes vers des chemins intra-régionaux. L'estimation avant et
15:47
Speaker 2: après atterrit dans le dépôt. Heure d'instance, niveau de stockage,
15:50
Speaker 2: transfert de données. La finance comprend les chiffres, donnez-leur des chiffres.
15:54
Speaker 2: Le réseau et la fiabilité ne sont pas non plus
15:56
Speaker 2: des réflexions après coup. Les modèles ajoutent des sondes de santé,
15:58
Speaker 2: des vérifications de préparation et le drainage des connexions pour
16:00
Speaker 2: que vos utilisateurs ne remarquent plus les déploies. Si la
16:02
Speaker 2: conformité exige des points de terminaison privés, ils les configurent,
16:05
Speaker 2: acheminent le trafic via Application Gateway ou Front Door et
16:07
Speaker 2: règlent des politiques simples que vous pouvez vraiment lire. Les
16:10
Speaker 2: journaux sont acheminés vers Azure Monitor avec des champs structurés.
16:13
Speaker 2: Tableau de bord préconfiguré, latence, taux d'erreur, saturation, la visibilité
16:17
Speaker 2: ennuyeuse de l'objectif. Le basculement suit un script, pas une intuition.
16:20
Speaker 2: L'agent prépare l'environnement, déploie sur un nouveau slot ou instance,
16:22
Speaker 2: le préchauffe avec du trafic synthétique et exécute des vérifications
16:25
Speaker 2: de contrat. Ensuite, une bascule, des TTLD laissent ajuster si nécessaire,
16:29
Speaker 2: un échange de slot pour App Service ou une répartition
16:30
Speaker 2: de trafic pour Spring Apps. Le plan de retour en
16:32
Speaker 2: arrière reste armé jusqu'à ce que le trafic utilisateur confirme
16:35
Speaker 2: le succès. Le rapport mentionne les fenêtres d'impact, qui a
16:37
Speaker 2: approuvé quoi et où se trouve l'issue de ce cours.
16:39
Speaker 2: C'est ainsi que vous évitez les légendes urbaines de 2h
16:41
Speaker 2: du matin. L'intégration des politiques assure la cohérence de l'ensemble.
16:44
Speaker 2: Approbation pour les changements sensibles à la sécurité, vérification de
16:47
Speaker 2: coûts pour les mises à niveau de plan et attestation
16:48
Speaker 2: de conformité intégrée au workflow. Chaque action est consignée dans
16:51
Speaker 2: GIT avec sa justification. Les auditeurs voient l'intention, le changement
16:54
Speaker 2: et la vérification. Pas de boîte noire, juste une chorégraphie
16:56
Speaker 2: disciplinée où l'agent effectue le travail difficile et où vous
16:59
Speaker 2: gardez les commandes. Résultats AWS dehors, Azure dedans, pipelines opérationnels,
17:03
Speaker 2: politiques appliquées et une facture cloud qui semble enfin jouer
17:05
Speaker 2: en votre faveur. Je vous en prie. Résultats et repères. Temps, CVE,
17:10
Speaker 2: coût et heure. Parlons résultats concrets, pas d'impression. Commençons par
17:14
Speaker 2: le calendrier. La séquence de mise à niveau et de
17:16
Speaker 2: migration qui engloutissait historiquement un trimestre est passée de moins
17:19
Speaker 2: à quelques jours. Heure d'évaluation et de planification. Mise à
17:22
Speaker 2: niveau Java 21 en quelques jours ouvrés. Préparation de la
17:24
Speaker 2: migration cloud et pipeline au sein du même sprint. Effet
17:27
Speaker 2: de calendrier. Les fonctionnalités ne font plus la queue derrière
17:29
Speaker 2: la saison des mises à niveau. Car il n'y a
17:30
Speaker 2: plus de saison, juste une automatisation disciplinée. On continue. Passons
17:34
Speaker 2: à la sécurité. Les CVE ne se soucient pas de
17:35
Speaker 2: votre feuille de route. L'agent a fait passer les vulnérabilités
17:38
Speaker 2: critiques élevées de cas présentes et exploitables qu'un réseau lupum
17:40
Speaker 2: a régénéré la SBOAM et produit des rapports d'analyse conformes
17:43
Speaker 2: à la réalité. Les éléments résiduels moyens et faibles ont
17:46
Speaker 2: été documentés avec des notes d'accessibilité et des délais de
17:48
Speaker 2: remédiation et des délais de remédiation. Le point crucial, la
17:51
Speaker 2: tendance des risques baisse et reste basse car le pipeline
17:53
Speaker 2: au scan a chaque changement. La réduction des coûts apparaît
17:55
Speaker 2: là où la finance regarde réellement. Heure de calcul ajustée
17:58
Speaker 2: à la charge réelle, environnement hors production configuré pour atteindre
18:01
Speaker 2: zéro si possible, et aigresse réduit par colocalisation des services bavards. Avant,
18:06
Speaker 2: des instances tournant au ralenti à un chiffre de CPU,
18:09
Speaker 2: des frais de transfert explosant sur les jobs nocturnes et
18:11
Speaker 2: du stockage gardant des données inutiles. Après, nombre d'instances alignées
18:15
Speaker 2: sur les courbes de demande, jobs batchs intra-régionaux et niveaux
18:17
Speaker 2: de stockage adaptés aux accès. Le chiffre qui a embarrassé
18:21
Speaker 2: la finance et ravi la sécurité, le coût mensuel total,
18:23
Speaker 2: a chuté tandis que le nombre de CVE diminuait. Moins
18:25
Speaker 2: de dollars, moins de vulnérabilité. Les deux courbes ont baissé ensemble.
18:29
Speaker 2: Ce n'est jamais un hasard. Les heures de développement récupérées
18:31
Speaker 2: ne sont pas théoriques. Les ingénieurs seniors ne perdent plus
18:33
Speaker 2: leur temps à gérer la roulette russe des dépendances et
18:35
Speaker 2: des builds fragiles. La boucle de l'agent, appliquer, construire, tester, patcher,
18:38
Speaker 2: remplace la partie la moins créative de leur travail. Ces
18:41
Speaker 2: heures sont réinvesties dans l'optimisation des performances, l'amélioration des points
18:44
Speaker 2: de terminaison, la suppression de fonctionnalités mortées, l'observabilité morte et l'observabilité.
18:48
Speaker 2: A l'échelle du portefeuille, le modèle se démultiplie. Une fois
18:50
Speaker 2: votre playbook dans Git, les autres applications l'adoptent et la
18:52
Speaker 2: taxe de mise à niveau 16 de s'accumuler. Le signal
18:55
Speaker 2: de fiabilité s'améliore car le pipeline impose une rigueur professionnelle.
18:58
Speaker 2: Les taux de succès des builds augmentent, les taux de
19:00
Speaker 2: réussite des tests se stabilisent après quarantaine et les tests
19:02
Speaker 2: de rollback deviennent un simple bouton plutôt qu'un rituel. La
19:05
Speaker 2: fréquence de déploiement augmente sans pénalité sur le taux d'erreur
19:07
Speaker 2: car la configuration des environnements dev, test et prod ne
19:10
Speaker 2: dérive plus. La confiance devient une métrique, pas un discours.
19:13
Speaker 2: La transparence assure la cohésion de l'ensemble. Chaque changement est
19:15
Speaker 2: un petit commis révisable avec justification et référence. Les rapports
19:18
Speaker 2: vivent aux côtés du code. Les auditeurs obtiennent leurs réponses
19:21
Speaker 2: sans avoir à solliciter les ingénieurs. La direction voit les coûts,
19:23
Speaker 2: les risques et la vélocité sur un seul écran. Et
19:25
Speaker 2: le pagé, c'est encore calme. Les chiffres comptent, vous les
19:29
Speaker 2: obtenez donc avec des justificatifs. Gouvernance, piste d'audit et transparence
19:33
Speaker 2: du modèle. Pas de boîte noire. La traçabilité est la base,
19:36
Speaker 2: pas une option. Chaque action finit dans Git avec une
19:39
Speaker 2: raison et un lien vers un avis, une recette ou
19:41
Speaker 2: une note de migration. Vous n'approuvez pas de la magie IA,
19:44
Speaker 2: vous approuvez des changements documentés précis. Ah, le retour arrière
19:47
Speaker 2: est un mec qui ne me guide pas une cellule
19:48
Speaker 2: de crise. L'explicabilité n'est pas optionnelle. L'agent joint des notes
19:52
Speaker 2: explicatives à chaque correctif. Quelle CVE? Quelle dépréciation d'API? Quelle directive? Azure?
19:58
Speaker 2: Les sorties du modèle correspondent aux normes que vous connaissez déjà.
20:00
Speaker 2: Si une suggestion dévie et le signale l'écart et attend
20:02
Speaker 2: une intervention humaine, le contrôle reste où il doit être.
20:05
Speaker 2: Les contrôles sont superposés, pas uniquement démonstratifs. Point de contrôle
20:08
Speaker 2: humain lors de l'approbation du plan, des changements sensibles et
20:10
Speaker 2: de la promotion d'environnement. Des portes conditionnelles se déclenchent si
20:14
Speaker 2: les Delta S Bohème sont importants, les coûts en hausse
20:16
Speaker 2: ou le réseau modifiés. La procédure d'urgence existe, est enregistrée
20:20
Speaker 2: et auditée a posteriori. Les adultes signent, les systèmes mémorisent.
20:24
Speaker 2: Le reporting est visible et ennuyeux, exactement comme il faut.
20:26
Speaker 2: Les tableaux de bord Power BI extraient les données de Git,
20:28
Speaker 2: des scanners et des pipelines. Temps gagné, tendance des CVE,
20:31
Speaker 2: courbe de coût, santé des déploiements. Vous pouvez filtrer par dépôt,
20:34
Speaker 2: équipe ou environnement. Cela signifie que les revues de gouvernance
20:37
Speaker 2: reposent sur des faits, pas sur des suppositions. La conformité
20:39
Speaker 2: est reproductible, car les preuves s'assemblent automatiquement. L'historique des commits,
20:43
Speaker 2: les S-bombs, les résultats de scans, les logs et approbations
20:46
Speaker 2: forment des artefacts d'audit alignés. Vous relancez le plan au
20:49
Speaker 2: trimestre suivant, et le résultat concorde, car le processus est identique. Alors,
20:53
Speaker 2: devez-vous encore corriger du Java hérité à la main? Non, évidemment.
20:57
Speaker 2: Voici ce qu'il faut retenir. La modernisation manuelle est un gaspillage.
21:00
Speaker 2: L'automatisation audité par agent est la nouvelle norme pour la vitesse,
21:03
Speaker 2: la sécurité et les coûts. Si cela vous a fait
21:06
Speaker 2: gagner du temps, soyez efficace, abonnez-vous. Ensuite, je connecterai Power
21:10
Speaker 2: BI et les déclencheurs de pipeline pour que vos rapports
21:13
Speaker 2: et déploiements soient autonomes. Activez les notifications et arrêtez d'apprendre
21:17
Speaker 2: par les pannes.