mvp

.dockerignore

@@ -0,0 +1,3 @@
+.venv
+.env
+output/*/

.gitattributes

@@ -33,3 +33,4 @@ saved_model/**/* filter=lfs diff=lfs merge=lfs -text
 *.zip filter=lfs diff=lfs merge=lfs -text
 *.zst filter=lfs diff=lfs merge=lfs -text
 *tfevents* filter=lfs diff=lfs merge=lfs -text
+articles/mocked_java9_openai_tts.wav filter=lfs diff=lfs merge=lfs -text

.gitignore

@@ -0,0 +1,5 @@
+.venv
+.env
+output/*/
+*.pyc
+__pycache__/

README.md

@@ -1,14 +1,15 @@
 ---
-title: UpVoice Str
+title: UpVoice
 emoji: 🚀
 colorFrom: red
 colorTo: red
 sdk: docker
 app_port: 8501
 tags:
-- streamlit
-pinned: false
-short_description: Streamlit template space
+  - streamlit
+  - tts
+pinned: true
+short_description: Générez un podcast à partir d'un de nos articles Tech
 ---
 
 # Welcome to Streamlit!

articles/Java9 ce mal aimé.md

@@ -0,0 +1,375 @@
+# Java 9, ce mal aimé
+
+Cet article n'a pas pour but de vous faire migrer vos applications vers Java 9, ni de faire l'apologie de Java 9, mais bien de montrer que cette version est méconnue et qu'elle a pu apporter énormément au langage et à notre quotidien. Elle a été précurseuse de certains sujets qui, aujourd'hui, font l'actualité de la communauté Java.
+
+L'ensemble des javaistes considère Java 8 comme une révolution du langage Java. Beaucoup d'applications en production sont d'ailleurs encore basées sur cette version.  
+Peu ont migré leurs applications de Java 8 à Java 9.  
+Alors pourquoi écrire un article sur Java 9 me direz-vous ? Simplement parce que ce dernier a apporté des nouveautés radicales et annoncées comme quasi révolutionnaires pour Java : la modularisation, les JAR multi-releases et l'algorithme G1GC comme Garbage Collector par défaut.
+
+Dans ce cas, pourquoi Java 9 n'a pas été aussi apprécié que Java 8 ? Connaissez-vous bien ce qu'il a réellement apporté au langage ?  
+À travers cet article, nous verrons une liste non exhaustive des JEP (JDK Enhancement Proposal) qui vous feront peut-être revoir votre copie. Saviez-vous par exemple que [Java 9 contient pas moins de 91 JEP](https://openjdk.org/projects/jdk9/) !!
+
+## Condensé des meilleures JEP de Java 9
+
+### [JEP 280: Indify String Concatenation](https://openjdk.org/jeps/280)
+
+Avant Java 9, le compilateur convertissait chaque concaténation de chaînes `String` en instructions StringBuilder. Avec cette approche, le code de concaténation était fixe et n'offrait pas de souplesse d'optimisation au moment de l'exécution. `StringBuilder` s'est tellement ancré en nous aujourd'hui, que bon nombre de développeurs l'utilise pour concaténer les chaînes de caractères.
+
+L'objectif de cette JEP était d'améliorer la concaténation de chaînes `String` en utilisant `invokedynamic` pour déléguer la concaténation à la factory `StringConcatFactory`.
+
+_Pourquoi ?_ Afin de permettre à la JVM d’optimiser **dynamiquement** les opérations de concaténation selon le contexte d'exécution, tout en conservant la simplicité de l’opérateur `+`.
+
+_Dans quel but ?_ En utilisant `invokedynamic`, la JVM peut désormais adapter les concaténations pour améliorer les performances, réduire les allocations intermédiaires et ajuster le code en fonction de l'environnement d'exécution.
+
+`invokedynamic` ? Instruction introduite par Java7, elle permet au bytecode d’appeler une méthode qui peut être résolue dynamiquement au moment de l'exécution.
+
+`StringConcatFactory` ? C’est la fabrique qui choisit la meilleure stratégie de concaténation (comme `StringBuilder`, `StringBuffer`, des concaténations de tableaux de bytes ou encore des structures de buffer internes à la JVM) selon les conditions d’exécution (nombre et type d'opérandes).
+
+Qu'est-ce que ça veut dire pour nous, développeurs ? Prenons l'exemple très simple suivant :
+
+```java
+String result = "Hello, " + name + "!";
+```
+
+Depuis Java 9, le compilateur ne traduit plus ce code en une séquence d'instructions avec StringBuilder (comme c'était le cas avant Java 9). Au lieu de cela, le compilateur Java génère une instruction `invokedynamic` dans le bytecode pour la concaténation de chaînes, qui ressemble à ceci : `INVOKEDYNAMIC makeConcatWithConstants(...)`
+
+Cette instruction demande à la JVM de décider au moment de l’exécution de la meilleure stratégie pour assembler les chaînes, en tenant compte du contexte exact. La JVM peut alors décider :
+
+- d'utiliser une instance de `StringBuilder` si la concaténation est simple,
+- de combiner directement les chaînes en une seule opération, si elles sont constantes et peuvent être optimisées ainsi, réduisant alors l'empreinte mémoire,
+- d’optimiser la concaténation de manière plus efficace que `StringBuilder` dans certains cas.
+
+Au moment de l'exécution, quand la JVM lit l’instruction `invokedynamic`, elle va déterminer dynamiquement (runtime) le meilleur moyen de réaliser l'opération de concaténation.  
+Elle invoque ensuite une méthode de "_bootstrap_" (ou méthode "d’assistance"), capable d’identifier l’implémentation la plus performante pour la concaténation.  
+Enfin, la JVM utilise cette stratégie pour toutes les concaténations similaires rencontrées, excepté si le contexte change, évidemment.
+
+Attention cependant aux cas complexes :
+
+- En concaténant un très grand nombre de chaînes (l'agrégation de données par exemple), même si Java optimise les concaténations, `StringBuilder` peut toujours être plus performant, car il permet de mieux gérer la mémoire et d'éviter les allocations répétées.
+- En construisant des chaînes de caractères à partir de nombreuses parties dynamiques, comme avec une utilisation de conditions ou d'opérations diverses, `StringBuilder` peut offrir une lisibilité et une maintenabilité accrues.
+- En concaténant des chaînes de caractères au sein d'une boucle, `StringBuilder` reste le plus efficace.
+
+Pour résumer, vous pouvez généralement faire confiance à ces optimisations pour fonctionner efficacement. Cependant, pour des constructions plus complexes ou répétitives, `StringBuilder` reste l'option à privilégier étant donné qu'elle est souvent plus performante.
+
+### [JEP 254: Compact Strings](https://openjdk.org/jeps/254)
+
+Cette JEP vise à optimiser la manière dont les chaînes de caractères `String` sont représentées/stockées en mémoire.
+
+Avant Java 9, les objets `String` étaient représentés par des tableaux de caractères `char[]`. Chaque caractère utilisait 2 octets (soit 16 bits) à cause de l'encodage utilisé : UTF-16.  
+Même si vos chaînes de caractères ne contenaient que des caractères ASCII (donc 1 octet par caractère), le fait que l'encodage soit réalisé avec UTF-16 entrainait une consommation mémoire excessive et inutile.
+
+Plusieurs changements ont donc été opérés :
+
+- La classe `String` utilise désormais un tableau d'octets `byte[]` au lieu d'un tableau de caractère `char[]` pour stocker les données.
+- Un champ supplémentaire de 1 bit, appelé `coder`, a été ajouté. Il est utilisé pour indiquer si la chaîne a été encodée en LATIN-1 (ou ASCII) ou en UTF-16, en prenant respectivement la valeur 0 ou 1.  
+  Si une chaîne contient uniquement des caractères ASCII (de 0 à 127), elle est alors stockée en utilisant 1 octet par caractère, sinon elle est stockée en UTF-16 comme auparavant.
+
+Il y a évidemment des cas où _Compact Strings_ ne s'applique pas. Par exemple, si votre chaîne contient des caractères non-ASCII, l'encodage se fera en UTF-16.
+
+Vous l'aurez compris, cette JEP réduit la consommation mémoire des chaînes `String`. Cette réduction de l'empreinte mémoire permet également un meilleur usage du cache CPU, pouvant améliorer les performances d'opérations sur les chaînes de caractères.
+
+Moins de consommation mémoire et une réduction des objets volumineux en mémoire veut aussi dire moins de pression sur le Garbage Collector.
+
+> **TIPS**  
+> Si votre application manipule beaucoup de chaînes de caractères (lecture de base de données, de fichiers...) et qu'elle n'a pas de contrainte en termes de latence ou de temps réel, il est conseillé d'activer l'option de la JVM de déduplication de `String` (`-XX:+UseStringDeduplication`) apportée par Java 8. Elle vous permettra de réduire encore l'empreinte mémoire de vos chaînes de caractères.  
+> Vous pouvez vérifier, lors de vos benchmarks, si cette option est réellement utile à votre application en affichant les statistiques sur cette déduplication via l'option `-XX:+PrintStringDeduplicationStatistics`.
+
+### [JEP 266: More Concurrency Updates](https://openjdk.org/jeps/266)
+
+Introduites en Java 8, les _CompletableFuture_ permettent de gérer des opérations asynchrones et non bloquantes (ie sans bloquer le thread principal).
+
+Java 9 améliore les _CompletableFuture_ en introduisant de nouvelles méthodes :
+
+- `delayedExecutor` permet d'exécuter une tâche après un délai spécifié,
+- `orTimeout` définit un délai au bout duquel une tâche échouera si elle n'est pas terminée,
+- `completeOnTimeout` permet de définir une valeur par défaut qui sera utilisée si la tâche n’est pas complétée avant le délai spécifié.
+
+### [JEP 269: Convenience Factory Methods for Collections](https://openjdk.org/jeps/269)
+
+Java 9 introduit des méthodes de factory pour créer des collections immuables de façon concise. Celles-ci sont beaucoup plus lisibles et pratiques, notamment pour des listes (ou ensembles). On y retrouve `List.of`, `Set.of` et `Map.of`.
+
+```java
+List<String> names = List.of("Foo", "Boo", "Fooboo");
+Set<Integer> numbers = Set.of(1, 2, 3);
+Map<String, Integer> map = Map.of("one", 1, "two", 2);
+```
+
+En plus d'être immuable (vous ne pouvez ni ajouter, ni modifier, ni supprimer des éléments), la collection n'allouera uniquement que le nombre d'éléments passés, et elle ne sera donc pas initialisée avec une capacité par défaut (10 pour un `ArrayList`, 16 pour une `HashSet` et 16 pour une `HashMap`). C'est également un gain en termes de consommation mémoire.
+
+### [JEP 213: Milling Project Coin](https://openjdk.org/jeps/213)
+
+#### Ajout de méthodes privées aux interfaces
+
+Depuis Java 9, nous pouvons désormais définir des méthodes privées (ou privées statiques) dans les interfaces.
+
+```java
+public interface MyCustomInterface {
+
+    default void myPublicMethod() {
+        privateHelper();
+    }
+
+    private void myPrivateHelper() {
+        System.out.println("Helper method");
+    }
+}
+```
+
+A première vue, ça semblait être une bonne approche. Mais nous pouvons vite nous demander quel avantage celle-ci pouvait réellement nous procurer...  
+La réponse était pourtant simple, cette fonctionnalité permet de factoriser du code commun aux méthodes `default` de l'interface.  
+Prenons l'exemple très simple d'une interface de calcul :
+
+```java
+public interface Calculator {
+    default int addAndDouble(int a, int b) {
+        int sum = a + b;
+        return sum * 2;
+    }
+
+    default int subtractAndDouble(int a, int b) {
+        int difference = a - b;
+        return difference * 2;
+    }
+}
+```
+
+Le code `return ... * 2` est dupliqué dans les deux méthodes par défaut. Cette JEP nous permet de factoriser comme suit :
+
+```java
+public interface Calculator {
+    default int addAndDouble(int a, int b) {
+        return doubleIt(a + b);
+    }
+
+    default int subtractAndDouble(int a, int b) {
+        return doubleIt(a - b);
+    }
+
+    private int doubleIt(int value) {
+        return value * 2;
+    }
+}
+```
+
+#### Amélioration du `try-with-resources`
+
+Vous le savez certainement, Java 7 a introduit la notion de `try-with-resources` permettant de fermer automatiquement les ressources implémentant `AutoCloseable`. Mais pour être fermée automatiquement, la ressource devait être déclarée dans le bloc `try`.
+
+Java 9 simplifie son utilisation en supprimant la déclaration d'une nouvelle variable locale au sein du bloc `try`.  
+Vous pouvez donc désormais déclarer une ressource en amont de votre `try-with-resources`, celle-ci sera toujours fermée en sortie de bloc.
+
+Avant Java 9 :
+
+```java
+... // code
+try (BufferedReader br = new BufferedReader(new FileReader("file.txt"))) {
+    ... // code
+}
+```
+
+Avec Java 9 :
+
+```java
+BufferedReader br = new BufferedReader(new FileReader("file.txt"));
+... // code
+try (br) {
+    ... // code
+}
+```
+
+#### Inférence de type dans les classes anonymes
+
+Depuis Java 9, l'inférence de type avec le diamant (`<>`) dans les classes anonymes est pris en charge.  
+Jusqu'à Java 9, nous déclarions une classe anonyme comme suit :
+
+```java
+Map<String, List<String>> myMap = new HashMap<String, List<String>>() {
+    // Classe anonyme
+};
+```
+
+Nous pouvons désormais la modifier en :
+
+```java
+Map<String, List<String>> myMap = new HashMap<>() {
+    // Classe anonyme
+};
+```
+
+L'avantage est relativement faible, mais cette amélioration réduit quand même la verbosité du code, tout en maintenant une inférence de type correcte.
+
+### [JEP 248: Make G1 the Default Garbage Collector](https://openjdk.org/jeps/248)
+
+Le G1GC, ou "Garbage First Garbage Collector", devient le Garbage Collector par défaut.
+
+Contrairement aux autres garbage collectors, G1GC n’est pas "en temps réel". Nous pouvons lui fixer des objectifs de performances spécifiques. Nous pouvons lui demander que les Stop-The-World ne dépassent pas x millisecondes dans un intervalle de temps donné de y millisecondes. Il fera alors de son mieux pour atteindre cet objectif avec une forte probabilité.
+
+Pour en savoir plus au sujet du G1GC et des garbage collectors en général, n'hésitez pas à lire nos articles [La Heap Java pour les nuls, mais pas que...](https://www.younup.fr/blog/la-heap-pour-les-nuls-mais-pas-que) et [La Heap Java pour les nuls, mais pas que... Round 2](https://www.younup.fr/blog/la-heap-java-pour-les-nuls-mais-pas-que-round-2).
+
+### [JEP 238: Multi-Release JAR Files](https://openjdk.org/jeps/238)
+
+Cette fonctionnalité permet de regrouper dans un seul JAR du code spécifique à différentes versions de Java. Cela facilite la compatibilité ascendante des bibliothèques et des frameworks. Par exemple, un JAR multi-releases peut contenir une classe compilée pour Java 8 et une version de cette même classe spécifique pour Java 9 et ultérieur.
+
+"Génial !" me direz-vous, mais malgré un avenir très prometteur sur le papier, cette JEP a littéralement fait un flop chez les javaistes. Voyons pourquoi.
+
+- La gestion de versions spécifiques dans un seul JAR rend clairement le code plus difficile à maintenir. Il faut s'assurer que les différentes versions de classes fonctionnent correctement ensemble et que les bonnes versions sont utilisées au bon moment.  
+  Par exemple, si une librairie a des fonctionnalités spécifiques pour Java 9, 10 et 11, mais pas pour Java 8, il devient plus (voire très) compliqué de maintenir le code si un bug est introduit dans l'une des versions spécifiques, car il faut tester et corriger chaque version de la classe à travers différentes versions de Java.
+- La prise en charge dans nos outils de build, comme Maven ou Gradle, ou dans certains de nos environnements d'exécution Java peut être incomplète ou nécessiter des configurations supplémentaires, et donc rendre la configuration du build bien plus complexe.
+- L'ajout de différentes versions de classes pour différentes versions de Java entraîne une certaine redondance dans le code. Certes, ça augmente la taille des fichiers JAR, mais ça peut également avoir un impact sur nos performances, surtout si de nombreuses versions sont incluses pour différentes versions de Java. De plus, si les classes spécifiques à une version de Java sont peu utilisées par notre code, l'ajout de ces versions supplémentaires dans le JAR devient inutile.  
+  La maintenance de ce code devient aussi plus complexe pour nous, car les modifications doivent être réalisées dans plusieurs versions de la même classe.
+- Si une classe utilise une API spécifique de Java 9, mais qu'elle dépend également d'une API de Java 8 pour certaines opérations, le gérer dans un seul JAR peut devenir très complexe, et rendre les bugs difficiles à localiser et à diagnostiquer, et donc difficiles à reproduire.
+- On ne va pas se le cacher, plutôt que de se fier aux JAR multi-releases, nous préférons tous gérer la compatibilité ascendante de manière explicite via nos chers gestionnaires de dépendances (Maven, Gradle...), où les différentes versions d'une bibliothèque peuvent être configurées explicitement. Ce n'est pas simple, mais c'est gérable.
+- Et pour finir, l'un des principaux points négatifs de cette JEP est son absence d'utilisation par les frameworks et librairies les plus populaires... Si les grands noms des frameworks Java n'ont pas adhéré, ça n'a clairement pas poussé la communauté à s'y intéresser.
+
+### [JEP 261: Module System](https://openjdk.org/jeps/261)
+
+Son but était d’introduire un système modulaire pour le JDK et de rendre le langage Java modulaire. Cela a permis de structurer la plateforme Java en modules distincts, afin de favoriser une gestion plus fine des dépendances, de réduire la taille des applications et d'améliorer la sécurité et les performances. Des très bons points !
+
+Pour modulariser nos modules Java au sein de notre application, chaque module Java est défini par un fichier `module-info.java`, placé à la racine de celui-ci. Ce fichier permet de spécifier le nom du module, ses dépendances (`requires`), et les paquets qu'il expose (`exports`). Assez simple, avouons-le.
+
+Cette JEP est, sans aucun doute, la plus importante de Java 9, mais aussi la plus boudée des développeurs. Elle est la JEP clé qui a posé les bases du système de modules Java, et elle fait partie du projet nommé _Jigsaw_.
+
+Mais sa complexité, son manque de compatibilité ascendante (librairies tierces non compatibles avec cette modularisation), mais aussi sans doute le fait que nous ayons tous perçus cette évolution comme une surcouche inutile (par rapport à la simplicité d'un monolithe codé en Java 8), ont freiné, voire empêché, son adoption par nous, les javaistes.
+
+Depuis, la modularisation monolithique est devenue un vrai sujet. La communauté parle de plus en plus de _Clean Architecture_ (pour en savoir plus, il est recommandé de lire "_Clean Architecture: A Craftman's Guide to Software Structure and Design_", écrit par Robert C. Martin, communément appelé _Oncle Bob_), et même Spring s'est engouffré dans la brèche avec la librairie "_Spring Modulith_" (voir l'article [Spring Modulith ou comment redonner vie à l'Architecture Monolithique](https://www.younup.fr/blog/spring-modulith-ou-comment-redonner-vie-a-larchitecture-monolithique)).
+
+### [JEP 295: Ahead-of-Time Compilation](https://openjdk.org/jeps/295)
+
+La JEP 295 a été introduite par Java 9 afin de permettre la précompilation de code Java avant son exécution.  
+Contrairement à la compilation _Just-In-Time_ (JIT) qui se produit lors de l'exécution du programme (runtime), la compilation AOT permettait de compiler certains morceaux du code Java en code machine avant même que le programme ne soit lancé.
+
+L’un des objectifs majeurs de cette JEP, expérimentale en Java 9, était de réduire le temps de démarrage des applications Java en se concentrant sur les classes et les méthodes peu (voire pas) dynamiques, afin de les rendre plus rapides à l'exécution, sans avoir besoin d'attendre que le compilateur _JIT_ effectue ses optimisations.  
+Etant donné que la JVM n'avait plus besoin, au runtime, de compiler les classes précompilées par AOT, l'empreinte mémoire était également plus faible.
+
+Les résultats n'ont certes pas toujours été au rendez-vous, et la prise en charge des optimisations était encore partielle. Mais cette expérimentation a ouvert la voix à la communauté vers la construction d'images natives afin d'améliorer drastiquement les temps de démarrage et la consommation de ressources, CPU et RAM.
+
+La JEP 483 fera partie de Java 24. Elle introduira une nouvelle approche pour le chargement et le linking des classes AOT. Contrairement à la JEP 295, elle ne reposera pas sur _jaotc_ mais sur un système basé sur CDS. Cette évolution visera à réduire les temps de démarrage en liant et chargeant les classes de manière prédictive pendant une phase de « training » avant exécution​.
+
+### [JEP 102: Process API Updates](https://openjdk.org/jeps/102)
+
+A travers cette JEP, Java 9 a apporté des améliorations à l'API _Process_, afin de mieux interagir avec les processus système, avec des méthodes pour obtenir l’identifiant du processus (PID), surveiller l’état, gérer les I/O de manière non bloquante, etc.
+
+```java
+// Crée un processus externe (par exemple, un simple "ping" à google)
+ProcessBuilder processBuilder = new ProcessBuilder("ping", "-c", "4", "google.com");
+Process process = processBuilder.start();
+
+// Obtenir et tracer l'ID du processus
+long pid = process.pid();
+System.out.println("ID du processus (PID) : " + pid);
+
+// Utilise onExit() pour obtenir un retour lorsqu'il se termine
+process.onExit().thenAccept(p -> {
+    try {
+        // Vérifie le code de sortie du processus
+        int exitCode = p.exitValue();
+        if (exitCode == 0) {
+            System.out.println("Le processus s'est terminé avec succès !");
+        } else {
+            System.out.println("Le processus a échoué avec le code de sortie : " + exitCode);
+        }
+    } catch (Exception e) {
+        ... // Traitement de l'exception
+    }
+});
+
+// code exécuté en parallèle du "ping"
+```
+
+La récupération du PID peut s'avérer utile si vous devez surveiller ou gérer un processus au niveau système, pour tuer le processus (en cas de freeze ou d'incident), ou pour un suivi dans des logs et/ou pour calculer des métriques (de performances).
+
+Contrairement à `process.waitFor()`, bloquant le thread principal jusqu'à ce que le processus se termine, l'utilisation de `onExit()` permet au programme de rester réactif et d'exécuter d'autres tâches pendant que le processus externe est en cours.
+
+### [JEP 222: JShell](https://openjdk.org/jeps/222)
+
+JShell est un REPL (Read-Eval-Print Loop) qui permet d’exécuter du code Java ligne par ligne, sans avoir besoin de compiler des classes entières. C’est un excellent outil pour tester du code rapidement, explorer des APIs ou apprendre Java.
+
+```java
+jshell>
+int a = 10;
+jshell>System.out.
+
+println(a +5);
+```
+
+### [JEP 259: Stack-Walking API](https://openjdk.org/jeps/259)
+
+Avant cette JEP, les méthodes existantes, comme `Thread.currentThread().getStackTrace()`, étaient coûteuses en termes de performance, car elles renvoyaient toujours une copie complète du tableau de _StackTraceElement_. Même si vous ne vouliez qu'une partie de la pile, vous étiez obligé d'obtenir et de parcourir tout le tableau.  
+Il n'y avait aucun moyen facile de filtrer les données sans parcourir manuellement tout le tableau.  
+L'accès était limité aux informations statiques de chaque élément, comme le fichier, le numéro de ligne, le nom de la méthode, mais pas à des informations dynamiques ou spécifiques au contexte.
+
+Cette nouvelle API permet donc de parcourir et d'interagir avec la pile d’appels de manière plus flexible et performante. Elle expose un Stream, que vous pouvez filtrer ou transformer facilement grâce aux outils de la programmation fonctionnelle (filter, map...).
+
+```java
+StackWalker walker = StackWalker.getInstance();
+walker.walk(stream ->
+    stream.filter(frame -> frame.getClassName().contains("MyClass"))
+          .forEach(System.out::println));
+```
+
+## Hors JEP
+
+### Amélioration de Optional
+
+Java 9 a ajouté des méthodes à `Optional` pour rendre le code plus concis :
+
+- `ifPresentOrElse` exécute une action si une valeur est présente, sinon il exécute une action différente
+
+  ```java
+    Optional<String> name = Optional.of("Cédric");
+    name.ifPresentOrElse( System.out::println, () -> System.out.println("No value")); // ici affiche Cédric
+  ```
+
+- `or` fournit un autre "Optional" si le premier est vide,
+- `stream` transforme "Optional" en un "Stream",
+- `orElseThrow` sans paramètre permet de lever une exception de type `NoSuchElementException` si aucune valeur n'est présente.
+
+Les nouvelles méthodes de Optional, comme ifPresentOrElse, rendent le code plus lisible et fluide, mais il est bon de noter qu'elles peuvent introduire une légère surcharge en raison de la gestion des objets encapsulés. Pour des cas critiques en performance, des alternatives plus simples peuvent être préférables : une vérification conditionnelle directe, avec _null_, sera en effet plus rapide.
+
+### Enrichissement de l'API Stream
+
+L’API _Stream_ a été enrichie avec de nouvelles méthodes utiles.
+
+- `takeWhile` et `dropWhile` permettent de limiter les éléments d’un flux en fonction d'une condition :
+
+  ```java
+  List<Integer> numbers = List.of(1, 2, 3, 4, 5);
+  numbers.stream()
+         .takeWhile(n -> n < 4)
+         .forEach(System.out::println); // Affiche 1, 2 et 3
+  ```
+
+  ```java
+   List<Integer> numbers = List.of(1, 3, 7, 12, 8, 5, 15);
+   List<Integer> result = numbers.stream()
+                                 .dropWhile(n -> n < 10)
+                                 .toList(); // result contient 12, 8, 5 et 15
+  ```
+
+- `iterate` avec condition, génère un flux fini ou infini avec une condition :
+
+  ```java
+   List<Integer> evenNumbers = Stream.iterate(0, n -> n <= 10, n -> n + 2)
+                                     .toList(); // evenNumbers contient 0, 2, 4, 6, 8 et 10
+  ```
+
+- `ofNullable` crée un flux d'un élément ou un flux vide si l'élément est null :
+
+  ```java
+        String nullableString = null;
+        Stream<String> stream = Stream.ofNullable(nullableString); // stream est vide
+
+        nullableString = "Hello, World!";
+        stream = Stream.ofNullable(nullableString); // stream contient "Hello, World!"
+  ```
+
+## Conclusion
+
+Certaines améliorations apportées par Java 9, bien que souvent discrètes, simplifient le code, augmentent les performances, et offrent des possibilités modernes pour gérer les flux de données, les processus, et la concaténation de chaînes.  
+Comme vous avez pu le remarquer, ces JEP sont nombreuses, et parfois même, vous les utilisez sans savoir qu'elles sont apparues avec Java 9.  
+Elles méritent quasiment toutes d’être explorées, car beaucoup d'entre elles enrichissent le langage tout en réduisant le besoin d’écrire du code supplémentaire.
+
+Le fait que Java 9 a été boudé par la communauté, celle-ci préférant migrer ses applications de Java 8 vers Java 11 ou Java 17, est principalement dû au fait que les JEP 261 (Modularisation) et 238 (Jar Multi-Releases) ont été les plus mises en avant, et considérées comme inutiles ou trop complexes par les développeurs.
+
+Pour finir, vous avez pu découvrir que cette version de Java apporta de nombreuses JEP très précieuses, qui continuent de vivre, comme la "Concaténation de Strings", le "Compact Strings", le G1GC par défaut, l'API "StackWalker"...  
+La JEP expérimentale "Compilation AOT" a été abandonnée, mais ses principes ont influencé des technologies modernes comme CDS, GraalVM et la future JEP 483, visant à réduire la consommation des ressources et à améliorer les performances.

articles/Les differents Patterns de Transactions Distribuees.md

@@ -0,0 +1,371 @@
+# Les différents Patterns de Transactions Distribuées
+
+Depuis quelques années, les architectures microservices et les systèmes distribués se multiplient, devenant une norme. Mais chaque solution, parfaite sur le papier, apporte son lot de difficultés et de complexité, comme par exemple la gestion des transactions distribuées, c'est-à-dire à travers de multiples services et bases de données.
+
+Les microservices, c'est top me direz-vous ! Les applications sont isolées, autonomes et gèrent leurs propres données... Ok, mais si chaque service fonctionne de manière autonome, avec ses propres ressources et bases de données, ayez bien à l'esprit qu'il est généralement essentiel que les données et les opérations restent cohérentes à travers l'ensemble du système. La gestion de la cohérence des données, surtout lorsqu'elles traversent plusieurs briques logicielles, entraîne de vrais défis, en particulier en termes de **cohérence**, de **fiabilité** et bien évidemment de **résilience**.
+
+C'est là qu'interviennent les **patterns de transactions distribuées**. Ceux-ci offrent des solutions élégantes pour gérer les transactions et les erreurs dans des systèmes où plusieurs services ou bases de données sont impliqués. Parmi les plus populaires, on trouve _Two-Phase Commit_ (2PC), _Three-Phase Commit_ (3PC), _Saga_, et d'autres approches permettant de garantir la consistance éventuelle, tout en assurant une gestion fine des erreurs et des "compensations" (rollback ou presque...).
+
+Dans cet article, j'explorerai en détail ces différents patterns, en mettant en lumière leurs avantages, les défis que représente leur mise en œuvre et des exemples d'applications concrètes. Nous verrons également comment ces approches s'intègrent dans des systèmes modernes utilisant des message brokers et des architectures asynchrones pour améliorer la résilience et la scalabilité des applications distribuées.
+
+## Définitions et Rappels
+
+Avant d'aborder les différents patterns, (re)voyons ensemble les différentes notions liées aux transactions.
+
+### Les Transactions
+
+Une **transaction** est _une séquence d'opérations traitées comme une unité indivisible. Elle garantit que les opérations qu’elle englobe sont soit entièrement exécutées, soit entièrement annulées. Si une transaction échoue à n'importe quel moment, toutes ses opérations doivent être annulées, afin de laisser le système dans un état cohérent._
+
+Le modèle **ACID**, ça vous parle ? C'est tout à fait ça. Une transaction doit répondre à 4 règles clés :
+
+- **A**tomicité : _Soit toutes les opérations de la transaction sont exécutées avec succès, soit aucune d’entre elles n’est exécutée._  
+  Cette propriété garantit que la transaction est une unité dite indivisible.
+- **C**ohérence : _la base de données passe d’un état cohérent à un autre état cohérent après une transaction_.  
+  Pour simplifier, une transaction transforme les données de manière à respecter les règles et contraintes définies sur la base de données (clés primaires, contraintes d'intégrité, d'unicité...).
+- **I**solation : _Les transactions doivent être exécutées de manière isolée les unes des autres._  
+  Les opérations d'une transaction ne doivent pas être visibles aux autres transactions tant qu’elles ne sont pas terminées.
+- **D**urabilité : dès qu’une transaction est validée (_commit_), les changements apportés par celle-ci doivent être permanents, même en cas de défaillance du système.
+
+Sur certaines bases de données SQL, la définition de l'isolation n'est pas forcément vraie, tout dépend du niveau d'isolation des transactions que vous avez choisi parmi les 4 généralement disponibles :
+
+- **Read UnCommitted** ne respecte pas complètement l'isolation
+- **Read Committed** respecte partiellement l'isolation
+- **Repeatable Read** respecte quasi-totalement l'isolation
+- **Serializable** respecte complètement l'isolation
+
+> Pour en savoir plus, je vous invite à lire cette [page](<https://en.wikipedia.org/wiki/Isolation_(database_systems)>) issue de Wikipédia.
+
+### Les Transactions Distribuées
+
+Une transaction distribuée implique plusieurs systèmes ou bases de données répartis sur plusieurs nœuds, serveurs ou même sites géographiques. Contrairement à une transaction classique, qui concerne une seule base de données, une transaction distribuée _doit garantir la cohérence et l'intégrité des données à travers plusieurs systèmes indépendants, voire hétérogènes_.
+
+Dans un contexte distribué, _une transaction doit être capable de s’étendre sur plusieurs ressources, et chaque ressource doit participer à l’opération transactionnelle_. Par exemple, un système pourrait impliquer plusieurs bases de données ou services web qui doivent collaborer dans le cadre d'une seule transaction. L'objectif reste de maintenir les propriétés **ACID** dans un environnement réparti, ce qui est clairement plus complexe que dans un environnement monolithique.
+
+Les transactions distribuées présentent **plusieurs défis de taille** par rapport aux transactions classiques :
+
+- La **Coordination** : coordonner différentes bases de données et services est complexe. Par exemple, un service peut réussir à effectuer une opération alors qu'un autre service échoue. Comment gérer ce genre de cas ?
+- La **Fiabilité et la Résilience** : les pannes peuvent se produire à tout moment dans un système distribué. Cela nécessite donc des mécanismes robustes pour gérer l’intégrité de la transaction.
+- La **Latence** : les communications entre différents systèmes répartis peuvent entraîner des latences importantes. Les transactions doivent être conçues de manière à minimiser les délais trop longs.
+
+> **A noter** : les bases de données NoSQL, souvent conçues pour des systèmes distribués, sacrifient certaines propriétés ACID pour garantir des performances élevées et la haute-disponibilité.
+
+L'exemple auquel tout le monde pense assez logiquement en lisant ces objectifs, est une application de _e-commerce_ ayant par exemple 4 services : la commande, la gestion des stocks, le paiement et la livraison.  
+Chacun de ces services peut être sur un serveur différent et utiliser une base de données différente.  
+La transaction doit garantir que si l’un de ces services échoue (par exemple, le paiement échoue), toute l’opération - réservation du stock et enregistrement de la commande - doit être annulée, assurant ainsi une cohérence globale.  
+Il est évident que dans un tel système, la notion d'**Atomicité** au sens propre du terme est perdue. Ici on parle alors de **cohérence à terme** par opposition à la **cohérence immédiate**.
+
+Maintenant, je suppose que vous vous rendez compte de la difficulté de tels systèmes distribués. Comment les rendre coordonnés, fiables, résilients et rapides ? Pour ça, il existe plusieurs patterns de coordination, tous assez différents, tous ayant leurs avantages et leurs inconvénients. Ouf ! 😮‍💨
+
+## Les Patterns de Transactions Distribuées
+
+Gardez en tête l'exemple d'un système applicatif d'e-commerce, c'est celui-ci qui servira à illustrer les différents patterns.
+
+### 2PC (Two-Phase Commit)
+
+Ce pattern est utilisé pour garantir l'atomicité des transactions distribuées en deux phases.
+
+- **Phase de préparation** :
+  - Le coordinateur demande à tous les participants s'ils peuvent valider la transaction.
+  - Chaque participant répond avec un vote (prêt ou échec).
+  - Si un participant répond "échec" lors de la phase de préparation, le coordinateur envoie une commande d'annulation à tous les participants qui ont répondu "prêt".
+  - Si tous les participants sont prêts, le coordinateur passe à la phase suivante.
+- **Phase de validation** :
+  - Si tous les participants répondent qu'ils sont prêts, le coordinateur envoie une commande de validation à tous les participants.
+  - Si un participant vote pour l'échec, le coordinateur envoie une commande d'annulation.
+
+"_Mais qui est ce coordinateur ?_" me direz-vous, et vous avez raison, je n'en ai pas encore parlé. Le coordinateur va dépendre du pattern de transactions distribuées utilisé.  
+Pour **2PC**, il s'agira généralement d'un module/composant indépendant afin d'assurer la séparation des préoccupations (_separation of concerns_) au sein du système.  
+"_Quel est son rôle ?_", simplement de maintenir le cycle de vie de la transaction, en appelant les différents modules concernés lors des deux phases. Si, à un moment donné, un module ne se prépare pas, ou si un module ne valide pas la transaction, le coordinateur est en charge d'interrompre la transaction et il commence alors la phase de compensation (_rollback_). Il est plus communément appelé "_Transaction Manager_".
+
+Le schéma ci-dessous représente les différents use-cases de 2PC dans un système e-commerce.
+
+![Ecommerce 2PC](imgs/2PC.svg)
+
+**Avantages** :
+
+- 2PC est un protocole de cohérence très fort.  
+  Tout d'abord, les phases de préparation et de validation garantissent que la transaction est atomique. La transaction se terminera soit par un retour réussi de tous les modules, soit par une absence de modification de tous les modules.
+- 2PC permet l'isolation lecture-écriture.  
+  Cela signifie que les modifications apportées à une entité ne sont pas visibles tant que le coordinateur ne les a pas validées.
+
+**Inconvénients** :
+
+- Bien que 2PC résolve le problème d'atomicité, il n'est pas vraiment recommandé pour de nombreux systèmes parce qu'il est synchrone, et donc bloquant.  
+  Le protocole doit verrouiller l'objet qui sera modifié avant que la transaction ne se termine.  
+  Si un objet "préparé" venait à être modifié, la phase de validation pourrait ne pas fonctionner.
+- Les pannes réseau, ou d'un participant, peuvent entraîner des verrouillages prolongés.
+
+Pour résumer, 2PC est un choix cohérent pour les systèmes nécessitant une **cohérence stricte**, il respecte le principe d'isolation des transactions, mais il n'est pas adapté aux systèmes à grande échelle ou à forte disponibilité, où les performances sont critiques.
+
+### 3PC (Three-Phase Commit)
+
+C'est une extension du 2PC avec une phase supplémentaire pour réduire les risques de blocage.
+
+- **Phase de canCommit** :
+  - Le coordinateur demande si les participants peuvent préparer la transaction.
+  - Si un participant répond "échec" à cette étape, la transaction est annulée immédiatement.
+- **Phase de preCommit** :
+  - Si tous les participants répondent "oui", le coordinateur envoie une pré-commande de validation.
+  - Si un participant ou le coordinateur échoue après cette phase, les participants passent en état de "_préparation à annuler_" ou à "_valider_" en fonction du dernier message reçu.
+  - Si une erreur survient, une commande d'annulation est envoyée.
+- **Phase de doCommit** :
+  - Le coordinateur envoie la commande finale de validation.
+  - Si une erreur se produit ici, une commande d'annulation est envoyée.
+
+Tout comme pour 2PC, le coordinateur ici est un module/composant indépendant, appelé "Transaction Manager".
+
+![Ecommerce 3PC](imgs/3PC.svg)
+
+**Avantages** :
+
+- Contrairement à 2PC, 3PC introduit une phase supplémentaire (_CanCommit_), qui permet aux participants de confirmer s’ils peuvent effectuer une transaction avant de passer à la phase de préparation.
+- En cas de panne réseau ou de défaillance du coordinateur, les participants peuvent prendre une décision autonome basée sur l'état de la transaction.
+- 3PC est conçu pour minimiser les risques de blocage total du système, le rendant plus tolérant aux pannes dans des environnements distribués.
+- Contrairement à 2PC, les participants peuvent revenir à un état cohérent sans attendre indéfiniment une réponse du coordinateur.
+
+**Inconvénients** :
+
+- 3PC est plus complexe que 2PC et il implique plus d'étapes de communication, introduisant donc plus de latence. Il est donc moins, voire peu, performant.
+
+Pour résumer, en raison de sa complexité et de ses exigences, 3PC est rarement utilisé en pratique. Les systèmes modernes préfèrent des alternatives comme **SAGA** ou des approches basées sur la **cohérence éventuelle**.
+
+> **A noter** : que ce soit 2PC ou 3PC, l'utilisation d'un message broker est inutile car les échanges sont gérés via les protocoles réseau (HTTP, TCP/IP...).
+
+### SAGA
+
+Le pattern **Saga** est sans doute le plus connu de tous. Il divise une transaction longue en une série de transactions plus petites, chacune avec une action compensatoire pour annuler l'effet en cas d'échec.
+
+- Chaque étape est une transaction locale.
+- Si une étape échoue, une série de transactions compensatoires est exécutée pour annuler les étapes précédentes (_rollback_).
+
+Il y a deux manières de mettre en œuvre le pattern _Saga_ : par **Choreography** ou par **Orchestration**. Ces deux approches définissent comment les différents services s’organisent pour gérer "la Saga".
+
+#### Saga Orchestration
+
+Dans le modèle **Orchestration**, un coordinateur central (ou _orchestrateur_) prend en charge la gestion de "la saga".  
+Ce dernier appelle les services dans un ordre précis et attend les résultats de chaque étape avant de passer à la suivante.  
+Si une étape échoue, le coordinateur décide de lancer les actions de compensation pour les étapes précédentes.
+
+Dans notre exemple d'e-commerce, l'orchestrateur gère la réservation, le paiement, et la livraison en appelant les services dans un ordre précis, en attendant les réponses de chaque service et en lançant des compensations si nécessaire.
+
+![ECommerce Saga et Orchestration](imgs/Saga_Orchestration.svg)
+
+**Avantages** :
+
+- Conçu pour les environnements microservices où chaque service possède son propre domaine de responsabilité et sa propre base de données.
+- La présence d'un orchestrateur centralisé simplifie la coordination inter-services.
+- Contraiement à 2PC, "Saga Orchestration" est **non bloquant** car chaque étape de la Saga est indépendante.
+- Il est capable de gérer les échecs partiels. L'orchestrateur peut appliquer des actions compensatoires en cas d'échec d'une étape, permettant de maintenir une **cohérence éventuelle**.
+- L'orchestrateur a une vue complète de l'état de la saga, ce qui facilite la supervision et la détection des échecs.
+
+**Inconvénients** :
+
+- **Complexité accrue** dans la gestion des transactions compensatoires.  
+  Écrire une logique de compensation pour chaque étape n’est pas trivial. Contrairement à un simple "_Ctrl+Z_" qui annule la dernière action de manière isolée, les transactions distribuées impliquent plusieurs services interconnectés, chacun ayant ses propres contraintes et effets secondaires. Il faut donc anticiper des cas comme l’annulation d’un paiement après l’expédition d’un produit, ou encore gérer des erreurs de compensation pour éviter des boucles infinies. 🤯  
+  Des frameworks comme _Temporal.io_, _Camunda_, _Axon Framework_ ou encore _Spring Cloud Data Flow_ peuvent vous aider car ils permettent d'orchestrer des workflows transactionnels, tout en ayant un mécanisme de compensation.
+- Non adapté pour toutes les opérations nécessitant une stricte atomicité. Ici, on parle de **cohérence éventuelle**.
+- Si l'orchestrateur tombe en panne, le système entier peut être impacté. Sa résilience doit être au coeur des préoccupations lors de sa conception.
+- Une **latence accrue**, l'orchestrateur introduisant une couche supplémentaire de communications et de traitements.
+
+Pour résumer, le modèle **Orchestration** du pattern Saga est pensé pour une architecture Microservices, mais la cohérence reste **éventuelle** (non applicable au domaine bancaire par exemple) et l'orchestrateur, étant perçu comme un **SPOF** (_Single Point Of Failure_), doit être résilient.
+
+#### Saga Choreography
+
+Contrairement au modèle _Orchestration_, il n'y a pas de coordinateur central. Chaque service qui participe, connaît les autres services et réagit de manière autonome aux événements déclenchés par ces derniers.
+
+Les services échangent des événements ou des messages et chacun est responsable de sa propre logique de compensation en cas d’échec.
+
+Dans notre système e-commerce, chaque service réagit à des événements comme par exemple "_Paiement confirmé_" ou "_Réservation annulée_", sans qu'il y ait pour autant un coordinateur central pour orchestrer l'ensemble.
+
+Avec ce modèle, un _message broker_ (Kafka, RabbitMQ...) est souvent utilisé, voire recommandé, pour publier et souscrire aux événements de chaque étape. Mais, fonction de vos appétences, ajouter un message broker à votre système est soit un avantage, soit un inconvénient 😊
+
+Dans le schéma suivant, je n'ai pas illustré le message broker afin d'en simplifier sa compéhension, vous devez juste imaginer que chaque échange passe par celui-ci.
+
+![ECommerce Saga et Choreography](imgs/Saga_Choreography.svg)
+
+**Avantages** :
+
+- Contrairement à la Saga de type Orchestration, chaque service est **responsable de son rôle**, réduisant la dépendance à un orchestrateur centralisé et supprimant ainsi le principal _SPOF_ du système applicatif.
+- Chaque service publie des événements et réagit aux événements d'autres services, ce qui favorise la **scalabilité** et l'**indépendance** des composants du système (voire des équipes).
+- La méthode Choregraphy facilite l'ajout de nouveaux services sans avoir à modifier un orchestrateur centralisé.
+- Les services ne dépendent que des événements qu'ils consomment ou émettent, ce qui permet une **flexibilité accrue** de leur évolution.
+
+**Inconvénients** :
+
+- L'absence d'une vue centralisée rend **difficile la supervision** et donc la détection d'échecs, en particulier dans des systèmes complexes.
+- Les services doivent connaître le **format des événements** et leur signification .
+  > 💡**Tips** : faites en sorte que les modifications des contrats d'interfaces soient rétrocompatibles.
+
+Au final, la méthode **Choregraphy** permet un couplage plus faible qu'avec _Orchestration_.  
+Elle est plus adaptée à une application où de nouveaux services peuvent apparaitre et disparaitre.  
+Toutefois, veillez à bien penser les étapes compensatoires de chaque module afin d'éviter les échecs en cascade.
+
+Vous l'aurez compris, quel que soit le modèle choisi, le pattern **Saga** se distingue des patterns classiques comme 2PC par sa capacité à garantir une **cohérence éventuelle** (donc non ACID) tout en évitant les blocages de ressources.
+
+Chaque étape d'une transaction est indépendante et je vous invite à l'accompagner d'une action compensatoire en cas d'échec.
+
+### TCC (Try-Confirm/Cancel)
+
+**TCC** est un pattern pour les transactions distribuées qui consiste en trois étapes :
+
+- **Try** : réserve les ressources nécessaires.  
+  Si une réservation échoue, la transaction est annulée immédiatement.
+- **Confirm** : Une fois que les ressources ont été réservées avec succès, la deuxième étape consiste à finaliser la transaction. À ce stade, la transaction est considérée comme terminée et les modifications sont appliquées de manière permanente.  
+  Si une erreur survient après cette étape, la transaction ne peut pas être annulée, car elle est déjà validée.
+- **Cancel** : Si une erreur se produit après la réservation des ressources, mais avant leur confirmation, une commande d'annulation est envoyée pour libérer les ressources réservées.  
+  Cela permet de revenir en arrière de manière sûre et de rétablir l'état du système avant la tentative de transaction.
+
+![ECommerce TTC](imgs/TTC.svg)
+
+**Avantages** :
+
+- **Flexibilité accrue** : la phase de réservation permet de réserver les ressources de manière temporaire et non bloquante, et seules les étapes de confirmation ou d'annulation prennent effet de manière définitive.  
+  Il est donc plus flexible que le 2PC qui utilise un verrouillage strict des ressources, et ce, pendant l'ensemble du processus.
+- **Isolation des étapes** : TCC garantit que les étapes de la transaction sont bien isolées, ce qui permet une gestion plus fiable des ressources dans un environnement distribué.
+- **Compensation en cas d'échec** : TCC offre une compensation en cas d'échec (via l'annulation). Si quelque chose échoue après la phase de réservation, les ressources peuvent être libérées rapidement, ce qui minimise l'impact sur le système.
+- **Plus flexible que 2PC** : chaque service gère indépendamment sa phase de validation ou d'annulation, alors que 2PC impose un verrouillage global et un coordinateur pour la gestion de la transaction.
+
+**Inconvénients** :
+
+- **Gestion complexe des compensations** : la gestion des réservations et des annulations peut devenir complexe car chaque service doit être capable de gérer les compensations de manière fiable et cohérente.
+- **Pas d'atomicité globale** : bien que chaque étape soit atomique au sein d'un service donné, les différentes étapes de la transaction peuvent échouer de manière indépendante, nécessitant une gestion des compensations pour maintenir la cohérence des données à travers les services.
+- **Complexité accrue** :
+  - un grand nombre de services doit être capable de gérer l'état de la transaction et de communiquer efficacement pour garantir que les annulations et confirmations se produisent au bon moment.
+  - des scénarios complexes, tels que des échecs simultanés dans différents services ou des situations où la gestion des compensations devient impossible, peuvent entraîner des états incohérents.
+
+En fin de compte, le pattern **TCC** est une solution efficace pour gérer les transactions distribuées.  
+Il permet de réserver les ressources de manière temporaire, puis de confirmer ou annuler la transaction selon les résultats. Ce pattern est plus flexible que le 2PC car il n'impose pas un verrouillage global des ressources.  
+Cependant, sa mise en œuvre peut être complexe, surtout quand il y a beaucoup de services impliqués, car chacun d'eux doit gérer l'annulation ou la confirmation de manière fiable.
+
+## Patterns de fiabilité et de cohérence
+
+Nous avons vu les patterns de transactions distribuées **2PC**, **3PC**, **SAGA** et **TCC**.  
+Ces derniers privilégient la gestion de l'**atomicité** et de la **cohérence des transactions** réparties sur plusieurs services et bases de données.  
+Ils garantissent ainsi que l'ensemble de la transaction soit entièrement complété avec succès, ou complètement annulé en cas d'échec.
+
+Cependant, il existe d'autres types de patterns qui ne visent pas une atomicité globale. N'ayant trouvé aucun terme pour qualifier cette catégorie de patterns, je les qualifierai de "**Patterns de fiabilité et cohérence**".  
+Ces approches se concentrent principalement sur la gestion des incohérences temporaires et la fiabilité des systèmes distribués. Les deux principaux patterns de cette catégorie sont **Transactional Outbox** et **Eventual Consistency**.
+
+### Transactional Outbox
+
+Méconnu, le pattern **Transactional Outbox** (que nous pourrions traduire par "_Boite aux lettres transactionnelle_") garantit que les mises à jour dans une base de données et les messages envoyés à un messages broker se produisent de manière atomique. On parle alors **d'atomicité locale**. La base de données garantit ainsi la cohérence transactionelle et le message broker gère la distribution asynchrone.
+
+Dans un système d'e-commerce :
+
+- Le service de commande crée une commande en base de données et écrit un message dans l'_outbox_ (table en base de données), et ce **dans la même transaction**.
+  - Si une transaction échoue avant de mettre à jour la base de données et l'écriture dans l'outbox, la transaction entière est annulée, y compris l'écriture de l'outbox.
+- Un service dit "_Message Relay_" scanne régulièrement la table _outbox_ pour y trouver les messages non encore envoyés.
+- Ces messages sont ensuite publiés dans un messages broker pour diffusion aux services consommateurs (stock, paiement, livraison).
+  - Si la transaction réussit mais l'envoi des messages échoue, les messages restent dans l'outbox jusqu'à ce qu'ils soient ré-envoyés avec succès.
+- Une fois un message envoyé avec succès, il est marqué comme traité ou supprimé de l’outbox.
+
+J'entends déjà votre question "_Pourquoi ne pas écrire directement dans le message broker plutôt que l'outbox ?_" 😁
+
+Si la sauvegarde de la commande en base de données réussit, mais que l'écriture dans le message broker échoue, le message est perdu. Il vous faudrait dans ce cas implémenter un mécanisme de retry ou un mécanisme de rollback de la commande, et vous en conviendrez, c'est moins facile.  
+De plus, on pourrait également imaginer le cas où l'écriture dans le message broker réussit, mais la sauvegarde de la commande échoue. Dans ce cas, le système se retrouverait avec un message diffusé pour une opération inexistante, et potentiellement, les services de paiement, de réservation de stock et de planification de livraison auraient réalisé des actions à tort... 😥
+
+Comme précédemment, je n'ai pas mentionné de message broker dans le schéma suivant afin d'en simplifier sa compéhension.
+
+![ECommerce Transactional Outbox](imgs/TransactionalOutbox.svg)
+
+**Avantages** :
+
+- La **simplicité** dans la mise en œuvre.
+- La **garantie** que les messages sont envoyés grâce à la persistance dans l’outbox.
+- La **cohérence stricte** de l'opération principale.  
+  Dans notre cas, la création d'une commande et son insertion dans l'outbox sont réalisées de manière **atomique**.
+- **Non bloquant**. Contrairement à 2PC, où l'ensemble des participants attendent la validation ou l'annulation, ici les opérations asynchrones évitent tout blocage.
+- **Scalable**.
+
+**Inconvénients** :
+
+- Nécessite un **Message Relay** pour lire l'outbox.
+- La table _outbox_ peut devenir un point de **contention** si le Message Relay est indisponible sur une longue période ou si les services consommateurs sont lents à traiter les messages.
+
+En définitive, le pattern **Transactional Outbox** garantit l'intégrité des messages dans des systèmes distribués.  
+En s'appuyant sur les transactions ACID pour sécuriser les opérations locales et un envoi asynchrone des messages, il assure que les données mises à jour sont toujours accompagnées de messages fiables envoyés aux autres services.  
+Ce pattern se différencie des autres par sa simplicité et son fonctionnement non bloquant.  
+Attention cependant à gérer efficacement la taille de la table _outbox_ et faites en sorte que le Message Relay ne deviennent un SPOF pour votre système.
+
+### Eventual Consistency
+
+Le pattern **Eventual Consistency** (ou _Cohérence Éventuelle_) repose sur l'idée que _les différents réplicas de données peuvent temporairement être incohérents, mais finiront par converger vers un état cohérent après un certain temps_.  
+Ce modèle est particulièrement utilisé dans des systèmes où la performance et la disponibilité sont capitales, même si cela entraîne des incohérences temporaires.
+
+Lors de l'édition des stocks dans un environnement avec de multiples points de vente (appelés _réplicas_ par la suite), la disponibilité et la rapidité d’accès sont primordiales, mais une petite incohérence temporaire dans les quantités disponibles est tolérable.
+
+Dans un système d'e-commerce :
+
+- Le service de commande crée une commande et publie un message via un message broker pour informer le service de gestion des stocks de la mise à jour des quantités disponibles, comme par exemple la décrémentation du stock.
+- Le service de gestion des stocks consomme ce message et applique la mise à jour.  
+  Cependant, cette mise à jour n'est pas immédiatement reflétée dans tous les réplicas, créant ainsi une incohérence temporaire dans les stocks entre les différents points de vente.
+- Si des mises à jour concurrentes arrivent sur les stocks (par exemple, deux commandes simultanées pour le même produit), des règles de réconciliation sont appliquées pour résoudre ces conflits, comme la mise à jour du stock en fonction de l’ordre des messages ou de la dernière mise à jour.
+- L’état du stock final est alors consigné et les mises à jour réussies sont enregistrées, ce qui permet d'éviter la duplication des événements et de **garantir que le système converge vers un état cohérent**.
+
+![ECommerce Eventual Consistency](imgs/EventualConsistency.svg)
+
+**Avantages** :
+
+- **Évolutif et résilient** : le système peut facilement s'adapter à une charge de travail croissante et maintenir une haute disponibilité.
+- **Faible latence et des performances élevées** : les mises à jour peuvent se produire rapidement, sans attendre la synchronisation complète des réplicas.
+
+**Inconvénients** :
+
+- **Difficile à concevoir et à dépanner** : les incohérences temporaires peuvent rendre la logique du système complexe à comprendre et à maintenir.
+- **Tolérance aux états intermédiaires inconsistants** : le système doit accepter que des données incohérentes puissent exister temporairement pendant que les réplicas convergent vers un état cohérent.
+
+Vous l'aurez compris, bien que ces deux patterns ne garantissent pas l'atomicité globale comme les patterns de transactions distribuées, ils améliorent la résilience, la disponibilité et la tolérance aux erreurs.  
+Grâce à leur gestion asynchrone des événements, ils permettent de maintenir la cohérence des données tout en offrant flexibilité et bonnes performances.  
+Vous comprenez désormais pourquoi je les apelle "patterns de fiabilité et de cohérence".
+
+## Et la Blockchain, on en parle ?
+
+La blockchain n'est pas un pattern de transaction distribuée à proprement parler.
+
+_C’est un registre de transactions distribuées, c’est-à-dire que l’information n’est ni centralisée, ni décentralisée, mais plutôt distribuée. La gouvernance des transactions se fait à partir de contrats intelligents, d’ententes entre les deux parties qui s’exécutent. Donc, si les conditions contractuelles ne sont pas remplies, la transaction n’est pas complétée._
+
+Si je devais la comparer avec les transactions distribuées, je dirais que la blockchain est une approche alternative qui garantit la cohérence et l'intégrité des transactions dans un environnement distribué.
+
+La blockchain ne nécessite pas de coordinateur central ni de mécanisme de rollback. À la place, elle utilise des algorithmes de **consensus distribué** ("_Proof of Work_", "_Proof of Stake_", "_Delegated Proof of Stake_", "_Proof of Autority_"...) pour valider et enregistrer les transactions **de manière immuable** (bien qu'il serait mieux de parler d'_immuabilité probabiliste_).
+
+Ce modèle est particulièrement adapté aux environnements où les participants ne se font pas confiance, comme dans les transactions financières.  
+En revanche, il introduit une latence plus élevée, ce qui le rend moins efficace pour les systèmes nécessitant une forte réactivité, comme les microservices transactionnels.
+
+Bien que les patterns de transactions distribuées et la blockchain partagent des objectifs similaires, ils répondent à des besoins différents : les premiers privilégient la rapidité et la flexibilité, tandis que la blockchain garantit la transparence et l’immutabilité au sein d'un réseau décentralisé.
+
+## Conclusion
+
+Les patterns de transactions distribuées comme _2PC_, _3PC_, _SAGA_ et _TCC_ visent à **garantir l'intégrité des données** dans des systèmes répartis.
+
+_2PC_ et _3PC_ offrent des solutions très strictes en termes d'atomicité, mais au prix de complexité et de risques de blocage (notamment avec 2PC).  
+3PC améliore 2PC en réduisant les risques de blocage, mais il reste assez rigide.
+
+_SAGA_ et _TCC_, quant à eux, privilégient la **flexibilité** en permettant une gestion asynchrone des transactions.  
+SAGA divise une grande transaction en sous-transactions avec des compensations possibles, tandis que TCC réserve d'abord les ressources, puis les confirme ou les annule selon le déroulement de la transaction.
+
+En parallèle, les patterns de fiabilité et de cohérence, comme _Transactional Outbox_ et _Eventual Consistency_, se concentrent sur la **gestion des incohérences temporaires** et la **fiabilité** des systèmes distribués, plutôt que sur l'atomicité stricte.  
+Ces patterns permettent une gestion asynchrone des événements et garantissent que les systèmes finissent par converger vers un état cohérent, tout en sacrifiant une cohérence immédiate pour une meilleure performance et une meilleure disponibilité.
+
+En résumé, le choix entre patterns de transactions distribuées et les patterns de fiabilité et de cohérence dépend des besoins spécifiques du système :
+
+- gestion stricte de l'atomicité avec 2PC ou 3PC,
+- flexibilité avec Saga ou TCC,
+- résilience et tolérance aux incohérences temporaires avec les autres patterns.
+
+Le compromis entre atomicité, performance et résilience est essentiel pour faire le bon choix. J'espère que cet article vous aidera à le faire... ce bon choix !
+
+Une dernière chose. Si vous êtes plutôt architecture monolithique modulaire que architecture microservices, ces patterns sont aussi applicables 😁
+
+> 📖 Sources :
+>
+> - Cohérence des données
+>   - [Wikipedia](<https://fr.wikipedia.org/wiki/Coh%C3%A9rence_(donn%C3%A9es)>)
+> - Propriétés ACID
+>   - [IBM](https://www.ibm.com/docs/en/cics-tx/11.1?topic=processing-acid-properties-transactions)
+> - Les Patterns
+>   - [Red Hat Developer Blog](https://developers.redhat.com/)
+>   - [Microservice Architecture](https://microservices.io/patterns/)
+>   - [Medium](https://medium.com/)
+> - La Blockchain
+>   - [Gestion](https://www.revuegestion.ca/la-technologie-blockchain-une-revolution-pour-la-chaine-d-approvisionnement)
+>   - [Coin Academy](https://coinacademy.fr/academie/differents-algorithmes-consensus-blockchain/)

articles/mocked_java9_openai_tts.wav

@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:10ce314db22cd099ef1ba07b2b591dfec58339d87fb17761d767f599c969bf6d
+size 8787500

articles/slidev.md

@@ -0,0 +1,282 @@
+# Codez votre PPT avec Slidev
+
+## Introduction
+
+Vous qui avez déjà peaufiné des dizaines de présentations PowerPoint, que ce soit pour une soutenance, un support de formation, des solutions techniques, ou d'adorables petits exposés scolaires 😇, savez-vous qu'il existe des alternatives logicielles à PowerPoint ou Keynote mais **ultra orientées dev** ?
+
+Il existe en réalité plusieurs projets comme [Reveal.js](https://revealjs.com/) ou [Marp](https://marp.app/) qui proposent concrètement d'utiliser un langage de programmation ou _équivalent_ pour préparer un diaporama avec du contenu multimédia et des animations.
+Mais aujourd'hui je vous invite à en découvrir un en particulier : [Slidev](https://sli.dev/).
+
+Slidev est un jeune projet Node.js Open Source et un peu "fou". Essentiellement écrit en TypeScript, il est doté d'une interface graphique en Vue.js.
+Il propose de **coder ses diapos à l'aide de Markdown enrichi**, un format assez simple et déjà bien connu de tous.
+
+À l'heure où j'écris ces lignes, Slidev est encore en version 0.49 – donc très expérimental – mais vous allez voir à travers ce tuto qu'il présente déjà quelques fonctionnalités qui valent vraiment le détour !
+
+> Note : pour ceux qui sont pressés, vous pouvez directement tester Slidev [ici](https://sli.dev/new).
+
+## Pourquoi diable s'embêter à coder un diaporama ?
+
+On pourrait croire qu'un pseudo langage comme le Markdown nous ferait économiser du temps d'écriture, comparé aux déplacements sinueux de la souris dans un logiciel classique (PowerPoint, Keynote, …).
+
+Oubliez ça.
+
+Bien que l'on puisse gagner un peu de temps lorsqu'on se contente d'un _layout_ très simple (car Slidev positionne automatiquement les éléments sur chaque diapositive avec le layout et le thème choisis), il y a une autre _vraie_ bonne raison : les **possibilités**.
+
+Les possibilités, c'est de pouvoir faire des présentations ultra techniques avec **une meilleure intégration de code** (une intégration de code tout court, en fait 😄). Vous pouvez par exemple montrer des extraits de code avec coloration syntaxique, créer des animations avancées sur des parties précises, intégrer des formules LaTeX, coder directement en [Vue.js](https://vuejs.org/) ou même ajouter des fonctionnalités dynamiques comme le "live coding" !
+
+Enfin, une autre bonne raison est de pouvoir mettre en place un système de synchronisation entre **un thème de référence** et celui appliqué sur le diaporama. Ainsi, votre diaporama suivra automatiquement les évolutions de la charte graphique de l'entreprise !
+
+Explorons maintenant ensemble toutes ces possibilités offertes par cette étonnante lib.
+
+## Codons un diaporama
+
+### La base
+
+Commencez par initialiser un projet Node.js en suivant les instructions [ici](https://sli.dev/guide/#create-locally) et créez un fichier d'entrée `slides.md` à la racine.
+
+Placez une image d'arrière-plan dans un répertoire `imgs`, et ajoutez alors ce contenu minimal dans votre fichier `slides.md` (pensez à adapter le chemin de votre image) :
+
+```markdown
+---
+background: ./imgs/background.webp
+---
+
+# Le titre de ma première diapo
+
+Créez des diapos tech et dynamiques !
+
+<!--
+Quelques notes réservées au présentateur pour la première diapo.
+-->
+```
+
+Lancez la commande `npm exec slidev -- --port 3030 "slides.md"`.
+Vous aurez alors accès à 3 espaces principaux :
+
+- une interface web sur `http://localhost:3030/` pour montrer le diaporama à votre public (et avec une **vignette caméra** déplaçable, trop cool !) :
+
+  ![Slidev présentation avec caméra](./imgs/slidev-pres.jpg)
+
+- une page `localhost:3030/presenter` pour contrôler votre diaporama en mode présentateur :
+
+  ![Slidev : mode présentateur](./imgs/slidev-presenter.jpg)
+
+- et une dernière page `localhost:3030/overview` histoire d'avoir un aperçu global de toutes vos diapos, même si vous préfèrerez sûrement l'affichage en grille depuis le mode présentateur (icône "Show slide overview").
+
+Vous pouvez également installer [une extension pour VS Code](https://marketplace.visualstudio.com/items?itemName=antfu.slidev) qui ajoute l'autocomplétion, vous permet de vous déplacer directement à une section depuis un titre, de réorganiser l'ordre des diapos, ou même d'avoir un aperçu en temps réel dans une vignette :
+
+![Intégration de Slidev dans VS Code](./imgs/slidev-vscode.jpg)
+
+Et tous ces espaces sont globalement synchronisés entre eux !
+
+> **Attention** : si vous utilisez Prettier, il faudra [le configurer](https://sli.dev/features/prettier-plugin) pour éviter les conflits avec ce Markdown un peu spécial !
+
+### Configurez le thème et les layouts
+
+Commençons à configurer les slides de notre diaporama.
+
+Il faut savoir que Slidev construit chaque diaporama en composant le contenu des fichiers `.md` avec **un thème graphique** et un ensemble de **layouts**.
+
+Tout d'abord je vous propose de choisir un thème dans la [galerie officielle](https://sli.dev/resources/theme-gallery).
+Vous pouvez le spécifier une (et une seule) fois dans ce que l'on appelle la partie `headmatter`, tout en haut du fichier Markdown :
+
+```markdown
+---
+theme: default
+transition: slide-left
+background: ./imgs/background.webp
+title: Mon premier diaporama
+---
+
+# Le titre de ma première diapo
+
+Créez des diapos tech et dynamiques !
+```
+
+Toutes les polices, tailles, couleurs et images par défaut seront automatiquement configurées !
+
+Notez bien les `---` avant et après l'en-tête, car ils délimitent la partie "en-tête" de la partie "contenu" pour chaque slide.
+
+Au passage, on en profite également pour configurer les animations entre chaque diapo : `transition: slide-left` qui va faire glisser la diapo suivante de la droite vers la gauche. Sobre, mais efficace.
+
+Ensuite, créez une nouvelle slide et ajoutez un layout `image-right`, dans la partie que l'on appelle alors `frontmatter` (tout un vocabulaire 😌).
+Ce layout vous permettra d'ajouter le chemin d'une image, qui peut tout à fait être une URL d'ailleurs !
+
+```markdown
+# Le titre de ma première diapo
+
+Créez des diapos tech et dynamiques !
+
+---
+
+layout: image-right
+image: https://domain.org/imgs/background.webp
+
+---
+
+Ici on ajoute du contenu uniquement sur la partie gauche de la diapo.
+```
+
+![Diapo avec une image à droite](./imgs/img-right.jpg)
+
+Il [existe](https://sli.dev/builtin/layouts) également les layouts `center`, `full`, `fact`, `iframe-right`, `quote`, etc.
+
+Il ne peut y avoir qu'**un seul thème par diaporama**, mais chaque slide peut avoir un layout différent.
+
+De manière générale, les layouts disponibles par défaut restent très simples et la plupart du temps, ils sont suffisants.
+Si toutefois vous cherchez une disposition personnalisée, il faudra soit aller chercher un plugin existant, soit écrire quelques lignes de code (cf. [doc officielle](https://sli.dev/guide/write-layout)).
+
+Maintenant, entrons dans le vif du sujet et expérimentons des contenus riches autour de code et de schémas qu'un logiciel de diaporama classique ne serait pas en mesure de gérer !
+
+### Présentez du code avec classe
+
+#### Extraits de code et animations
+
+Dans la diapo que vous venez de créer, commencez par ajouter un extrait de code de la même façon qu'en Markdown :
+
+![Extrait de code Hello World en markdown](./imgs/md-helloworld-code.png)
+
+![Rendu de la slide 2 Hello World](./imgs/slide-2.jpg)
+
+On obtient une présentation basique du code avec coloration syntaxique et le texte sélectionnable.
+
+Mais avec le Markdown enrichi que nous propose Slidev, nous allons pouvoir ajouter des options très intéressantes, comme l'affichage du numéro des lignes et la **surbrillance successive** des lignes 5, 1 puis 2 au clic de souris (ou les flèches du clavier), comme si l'on simulait un débogage !
+
+![Animation du code en Markdown](./imgs/md-anim-code.png)
+
+![Rendu de l'animation de code](./imgs/slidev-anim-code.gif)
+
+Et si on allait un peu plus loin dans les animations ?
+
+Imaginez que vous souhaitiez présenter une refactorisation ou tout simplement un JSON, par exemple, qui évoluerait plusieurs fois, successivement.
+Eh bien, vous allez pouvoir animer ce code automatiquement avec la feature `shiki-magic-move` pour mettre en évidence ces évolutions :
+
+![Exemple code Shiki-magic-move](./imgs/shiki-magic-move-code.png)
+
+Et le rendu slidev, toujours animé au clic de souris ou flèches clavier :
+
+![Rendu Slidev avec Shiki-magic-move](./imgs/slidev-shiki-magic-move.gif)
+
+Magique ! 😲
+
+#### Live Coding
+
+Nous venons de voir la présentation de code statique. Maintenant nous allons construire une slide qui va nous permettre de réaliser **une démonstration de code en direct**, et sans quitter la présentation.
+
+Ajoutez une nouvelle slide avec un layout de type `full` pour un affichage confortable. Puis ajoutez la suite de Fibonacci dans un extrait de code avec la mention `{monaco-run}` pour activer l'éditeur.
+
+![Code Markdown pour du live coding](./imgs/md-live-coding.png)
+
+L'éditeur Monaco intégré va alors nous permettre de modifier le code en direct avec le linter, l'autocomplétion, et même l'exécution en temps réel !
+
+![Live coding dans Slidev](./imgs/slidev-live-coding.gif)
+
+### Construisez des schémas avancés
+
+Slidev prend en charge les graphes [PlantUML](https://plantuml.com/) et [Mermaid](https://mermaid.js.org/). Si vous ne connaissez pas encore ce dernier, je vous conseille d'aller faire un tour sur [notre article ici](https://www.younup.fr/blog/graphes-avec-mermaid).
+
+Mermaid offre beaucoup plus de possibilités qu'un système de drag-n-drop de formes qu'on trouverait dans un logiciel classique : diagrammes de séquence, classes, mindmap, git graph…
+
+Ici je vous propose de partir sur un diagramme de Gantt, car c'est typiquement le genre de diagramme qui pourrait décourager à dessiner dans un soft classique.
+
+Créez une nouvelle slide intitulée "Organisation du projet", avec le layout `default` qui, ici, convient à un diagramme qui a tendance à s'étendre sur la longueur. Ensuite, vous allez pouvoir ajouter directement un extrait de code de type `mermaid` pour dessiner un [diagramme de Gantt](https://mermaid.js.org/syntax/gantt.html), par exemple, sur l'organisation des développements d'une appli web entre une équipe UI/UX, une front, et une back.
+
+![Gantt avec mermaid](./imgs/md-mermaid.png)
+
+Ce qui nous génère un magnifique diagramme de Gantt dans notre diapo !
+
+![Rendu slidev du diagramme de Gantt avec Mermaid](./imgs/slidev-mermaid.png)
+
+Comme vous pouvez le constater, la syntaxe nécessite quand même une _certaine_ prise en main. Mais avec un peu d'expérience, l'écriture, et surtout, la mise à jour du diagramme dans le diaporama deviennent très intéressantes !
+
+### Multipliez les possibilités avec des composants externes
+
+Dans cette partie nous allons pousser l'intégration d'éléments externes en combinant une scène 3D du système solaire avec un `Component` Vue.js dans une seule et même diapositive.
+
+Tout d'abord, commençons par créer une diapo très simple, qui va juste se contenter d'afficher notre composant Vue.js :
+
+```markdown
+---
+title: Contenus externes
+layout: full
+---
+
+# Un composant Vue.js dynamique
+
+<PlanetTeleporter />
+```
+
+Ensuite, créez un fichier `components/PlanetTeleporter.vue` à la racine du projet.
+
+Dans ce nouveau composant, nous allons construire :
+
+- un `iframe` ouvert sur une page web intégrant un système solaire en 3D (basé sur [Three.js](https://threejs.org/)) ;
+- et un bouton superposé qui va légèrement modifier l'URL de la scène 3D pour se téléporter directement à la planète Saturne.
+
+```html
+<script setup lang="ts">
+  import { ref } from "vue";
+
+  const url = ref("https://eyes.nasa.gov/apps/solar-system/");
+
+  function toSaturn() {
+    url.value = "https://eyes.nasa.gov/apps/solar-system/#/saturn";
+  }
+</script>
+
+<template>
+  <section>
+    <iframe :src="url" title="Page externe système solaire"></iframe>
+    <button @click="toSaturn">Vers Saturne !</button>
+  </section>
+</template>
+
+<style scoped>
+  section {
+    position: relative;
+    height: 85%;
+  }
+
+  button {
+    position: absolute;
+    left: 380px;
+    top: 15px;
+    border: 1px solid white;
+    color: white;
+    width: 120px;
+    padding: 5px;
+    font-family: mono;
+    background-color: black;
+  }
+
+  button:hover {
+    background-color: gray;
+  }
+
+  iframe {
+    width: 100%;
+    height: 100%;
+  }
+</style>
+```
+
+Si vous regardez alors le rendu :
+
+![Rendu slidev du système solaire dynamique](./imgs/slidev-to-saturn.webp)
+
+… et toujours sans quitter votre slide !
+
+Imaginez maintenant tout ce que vous allez pouvoir faire en intégrant des composants dynamiques encore plus avancés, ou en manipulant directement du SVG pour une qualité graphique toujours nickel ! 🤩
+
+Maintenant, vous avez toutes les clés en main pour créer des diaporamas techniques complètement dingues !
+
+Et si vous cherchez encore de l'inspiration, je vous invite à jeter un œil à [la galerie d'exemples](https://sli.dev/resources/showcases).
+
+## Conclusion
+
+À travers ce tuto, nous avons pu explorer de nombreuses fonctionnalités qu'offre la lib Slidev, surtout d'un point de vue **intégration de code dynamique, de schémas et contenus externes**.
+
+Avec du recul, on constate également que Slidev est un projet encore très récent, qui manque peut-être encore un peu de stabilité et d'uniformité dans la syntaxe par rapport à d'autres projets comme Reveal.js.
+Par ailleurs, dès que l'on souhaite une disposition ou une animation particulière, la tâche peut rapidement s'annoncer plus ardue que prévu et nécessiter un investissement assez important. Mais au bout du compte, le jeu en vaut peut-être la chandelle ?
+
+Et comme je le disais au début de ce tuto, ce qui nous intéresse surtout ici, ce sont les possibilités !

dev.sh

@@ -0,0 +1,2 @@
+#!/bin/bash
+PYTHONPATH=./src streamlit run ./src/streamlit_app.py

requirements.txt

@@ -1,3 +1,9 @@
-altair
-pandas
-streamlit
+streamlit
+pydub
+openai
+pypdf
+edge_tts
+python_dotenv
+langchain
+langchain-openai
+langchain-community

src/audio_generation.py

@@ -0,0 +1,141 @@
+from dataclasses import dataclass
+from typing import List, Tuple
+import os
+from openai import OpenAI
+import tempfile
+from pydub import AudioSegment
+import base64
+from pathlib import Path
+from script_generation import PodScript
+@dataclass
+class AudioConfig:
+    output_path: str = "./output"
+    api_key: str = os.getenv("OPENAI_API_KEY", "")
+    model: str = "gpt-4o-mini-tts"
+    mocked: bool = False
+
+class ScriptToAudio:
+    def __init__(self, config: AudioConfig):
+        self._config = config
+        self._llm_client = OpenAI(api_key=config.api_key)
+
+    async def _text_to_speech(self, script: PodScript, voice_1: str, voice_2: str) -> Tuple[List[str], str]:
+        """Converts the text in the conversation JSON to speech using the specified voices.
+        Args:
+            conversation_json (Dict): The conversation JSON containing the text to be converted.
+            voice_1 (str): The voice for the first speaker.
+            voice_2 (str): The voice for the second speaker.
+        Returns:
+            Tuple[List[str], str]: A tuple containing a list of filenames of the generated audio files and the output directory.
+        Raises:
+            ValueError: If the conversation JSON is empty or if the voices are invalid.
+            RuntimeError: If the text-to-speech conversion fails.
+        """
+        output_dir = Path(self._create_output_directory())
+        filenames = []
+
+        try:
+            for i, line in enumerate(script.conversation):
+                filename = output_dir / f"output_{i}.wav"
+                voice = voice_1 if i % 2 == 0 else voice_2
+
+                tmp_path= await self._generate_audio(line.text, voice)
+                os.rename(tmp_path, filename)
+                filenames.append(str(filename))
+
+            return filenames, str(output_dir)
+        except Exception as e:
+            raise RuntimeError(f"Failed to convert text to speech: {e}")
+
+
+    async def _generate_audio(self, text: str, voice: str) -> str:
+        """Generates audio from the given text using the specified voice.
+        Args:
+            text (str): The input text to be converted to audio.    
+            voice (str): The voice to be used for the audio generation.
+        Returns:
+            str: Astring containing the filename of the generated audio file.
+        Raises:
+            RuntimeError: If the audio generation fails.
+        """
+        try:
+            with tempfile.NamedTemporaryFile(delete=False, suffix=".wav") as tmp_file:
+
+                response = self._llm_client.audio.speech.create(
+                    model=self._config.model,
+                    voice=voice.lower(),
+                    input=text,
+                    response_format="wav"
+                )
+                usage = response 
+                tmp_path = tmp_file.name
+                with open(tmp_path, "wb") as f:
+                    f.write(response.content)
+                """ with self._llm_client.audio.speech.with_streaming_response.create(
+                    model=self._config.model,
+                    voice=voice.lower(),
+                    input=text,
+                ) as response:
+                    response.stream_to_file(tmp_path) """
+
+            return tmp_path
+        except Exception as e:
+            raise RuntimeError(f"Failed to generate audio: {e}")
+
+
+
+    def _create_output_directory(self) -> str:
+        """Creates a unique output directory for the generated audio files.
+        Returns:
+            str: The name of the created output directory.
+        Raises:
+            RuntimeError: If the directory creation fails.
+        """
+        random_bytes = os.urandom(8)
+        folder_name = base64.urlsafe_b64encode(random_bytes).decode("utf-8")
+        final_folder_name = os.path.join(self._config.output_path, folder_name)
+        os.makedirs(final_folder_name, exist_ok=True)
+        return final_folder_name
+
+    def _combine_audio_files(self, filenames: List[str], output_file: str) -> None:
+        """Combines multiple audio files into a single WAV file.
+        Args:
+            filenames (List[str]): A list of filenames of the audio files to be combined.
+            output_file (str): The name of the output WAV file.
+        Raises:
+            ValueError: If the input filenames list is empty.
+            RuntimeError: If the audio file combination fails.
+        """
+        if not filenames:
+            raise ValueError("No input files provided")
+
+        try:
+            audio_segments = []
+
+            for filename in filenames:
+                audio_segment = AudioSegment.from_mp3(filename)
+                audio_segments.append(audio_segment)
+
+            combined = sum(audio_segments, AudioSegment.empty())
+
+            combined.export(output_file, format="wav")
+
+            for filename in filenames:
+                os.remove(filename)
+
+        except Exception as e:
+            raise RuntimeError(f"Failed to combine audio files: {e}")
+
+    async def run(self, script:PodScript ,voice_1: str, voice_2: str) -> str:
+        if self._config.mocked:
+            return './articles/mocked_java9_openai_tts.wav'
+
+        try:
+            audio_files, folder_name = await self._text_to_speech(
+                    script, voice_1, voice_2
+            )
+            final_output = os.path.join(folder_name, "combined_output.wav")
+            self._combine_audio_files(audio_files, final_output)
+            return final_output
+        except Exception as e:
+            raise RuntimeError(f"Failed to convert article to podcast: {e}")

src/audio_generation_edge.py

@@ -0,0 +1,141 @@
+from dataclasses import dataclass
+from typing import List, Tuple
+import os
+from openai import OpenAI
+import tempfile
+from pydub import AudioSegment
+import base64
+from pathlib import Path
+from script_generation import PodScript
+@dataclass
+class AudioConfig:
+    output_path: str = "./output"
+    api_key: str = os.getenv("OPENAI_API_KEY", "")
+    model: str = "gpt-4o-mini-tts"
+    mocked: bool = False
+
+class ScriptToAudio:
+    def __init__(self, config: AudioConfig):
+        self._config = config
+        self._llm_client = OpenAI(api_key=config.api_key)
+
+    async def _text_to_speech(self, script: PodScript, voice_1: str, voice_2: str) -> Tuple[List[str], str]:
+        """Converts the text in the conversation JSON to speech using the specified voices.
+        Args:
+            conversation_json (Dict): The conversation JSON containing the text to be converted.
+            voice_1 (str): The voice for the first speaker.
+            voice_2 (str): The voice for the second speaker.
+        Returns:
+            Tuple[List[str], str]: A tuple containing a list of filenames of the generated audio files and the output directory.
+        Raises:
+            ValueError: If the conversation JSON is empty or if the voices are invalid.
+            RuntimeError: If the text-to-speech conversion fails.
+        """
+        output_dir = Path(self._create_output_directory())
+        filenames = []
+
+        try:
+            for i, line in enumerate(script.conversation):
+                filename = output_dir / f"output_{i}.wav"
+                voice = voice_1 if i % 2 == 0 else voice_2
+
+                tmp_path= await self._generate_audio(line.text, voice)
+                os.rename(tmp_path, filename)
+                filenames.append(str(filename))
+
+            return filenames, str(output_dir)
+        except Exception as e:
+            raise RuntimeError(f"Failed to convert text to speech: {e}")
+
+
+    async def _generate_audio(self, text: str, voice: str) -> str:
+        """Generates audio from the given text using the specified voice.
+        Args:
+            text (str): The input text to be converted to audio.    
+            voice (str): The voice to be used for the audio generation.
+        Returns:
+            str: Astring containing the filename of the generated audio file.
+        Raises:
+            RuntimeError: If the audio generation fails.
+        """
+        try:
+            with tempfile.NamedTemporaryFile(delete=False, suffix=".wav") as tmp_file:
+
+                response = self._llm_client.audio.speech.create(
+                    model=self._config.model,
+                    voice=voice.lower(),
+                    input=text,
+                    response_format="wav"
+                )
+                usage = response 
+                tmp_path = tmp_file.name
+                with open(tmp_path, "wb") as f:
+                    f.write(response.content)
+                """ with self._llm_client.audio.speech.with_streaming_response.create(
+                    model=self._config.model,
+                    voice=voice.lower(),
+                    input=text,
+                ) as response:
+                    response.stream_to_file(tmp_path) """
+
+            return tmp_path
+        except Exception as e:
+            raise RuntimeError(f"Failed to generate audio: {e}")
+
+
+
+    def _create_output_directory(self) -> str:
+        """Creates a unique output directory for the generated audio files.
+        Returns:
+            str: The name of the created output directory.
+        Raises:
+            RuntimeError: If the directory creation fails.
+        """
+        random_bytes = os.urandom(8)
+        folder_name = base64.urlsafe_b64encode(random_bytes).decode("utf-8")
+        final_folder_name = os.path.join(self._config.output_path, folder_name)
+        os.makedirs(final_folder_name, exist_ok=True)
+        return final_folder_name
+
+    def _combine_audio_files(self, filenames: List[str], output_file: str) -> None:
+        """Combines multiple audio files into a single WAV file.
+        Args:
+            filenames (List[str]): A list of filenames of the audio files to be combined.
+            output_file (str): The name of the output WAV file.
+        Raises:
+            ValueError: If the input filenames list is empty.
+            RuntimeError: If the audio file combination fails.
+        """
+        if not filenames:
+            raise ValueError("No input files provided")
+
+        try:
+            audio_segments = []
+
+            for filename in filenames:
+                audio_segment = AudioSegment.from_mp3(filename)
+                audio_segments.append(audio_segment)
+
+            combined = sum(audio_segments, AudioSegment.empty())
+
+            combined.export(output_file, format="wav")
+
+            for filename in filenames:
+                os.remove(filename)
+
+        except Exception as e:
+            raise RuntimeError(f"Failed to combine audio files: {e}")
+
+    async def run(self, script:PodScript ,voice_1: str, voice_2: str) -> str:
+        if self._config.mocked:
+            return './articles/mocked_java9_openai_tts.wav'
+
+        try:
+            audio_files, folder_name = await self._text_to_speech(
+                    script, voice_1, voice_2
+            )
+            final_output = os.path.join(folder_name, "combined_output.wav")
+            self._combine_audio_files(audio_files, final_output)
+            return final_output
+        except Exception as e:
+            raise RuntimeError(f"Failed to convert article to podcast: {e}")

src/config.py

@@ -0,0 +1,42 @@
+voice_names = {
+    "Alloy": "aloy",
+    "Ash": "ash",
+    "Ballad": "ballad",
+    "Coral": "coral",
+    "Echo": "echo",
+    "Fable": "fable",
+    "Onyx": "onyx",
+    "Nova": "nova",
+    "Sage": "sage",
+    "Shimmer": "shimmer",
+    "Verse": "verse"
+}
+
+quality_options = {
+    "Basse (gratuite)": "low",
+    "Haute (payante)": "high"
+}
+
+default_speaker_1 = 0
+default_speaker_2 = 1
+
+languages = [
+    "Langue de la source",
+    "Afrikaans", "Albanian", "Amharic", "Arabic", "Armenian", "Azerbaijani",
+    "Bahasa Indonesian", "Bangla", "Basque", "Bengali", "Bosnian", "Bulgarian",
+    "Burmese", "Catalan", "Chinese Cantonese", "Chinese Mandarin",
+    "Chinese Taiwanese", "Croatian", "Czech", "Danish", "Dutch", "English",
+    "Estonian", "Filipino", "Finnish", "French", "Galician", "Georgian",
+    "German", "Greek", "Hebrew", "Hindi", "Hungarian", "Icelandic", "Irish",
+    "Italian", "Japanese", "Javanese", "Kannada", "Kazakh", "Khmer", "Korean",
+    "Lao", "Latvian", "Lithuanian", "Macedonian", "Malay", "Malayalam",
+    "Maltese", "Mongolian", "Nepali", "Norwegian Bokmål", "Pashto", "Persian",
+    "Polish", "Portuguese", "Romanian", "Russian", "Serbian", "Sinhala",
+    "Slovak", "Slovene", "Somali", "Spanish", "Sundanese", "Swahili",
+    "Swedish", "Tamil", "Telugu", "Thai", "Turkish", "Ukrainian", "Urdu",
+    "Uzbek", "Vietnamese", "Welsh", "Zulu"
+]
+
+articles =[
+            ("Java 9, ce mal aimé", "Java9 ce mal aimé.md")
+        ]

src/mocked_script.py

@@ -0,0 +1,19 @@
+mocked_raw_script = """
+Alloy : Salut tout le monde, et bienvenue dans "Tech Talk with Alloy and Ash"! Aujourd'hui, on va traîner du côté des coulisses des technologies Java, et plus précisément, le mystérieux et souvent mal compris Java 9! [pause] Bonjour Ash!
+Ash : Salut Alloy! Franchement, c'est marrant, mais Java 9, c'est un peu comme ce film culte que personne n'a regardé au cinéma mais qui est devenu un classique dans les bacs. Pourquoi as-tu pensé à Java 9 pour notre podcast aujourd'hui?
+Alloy : Ah, super question! En fait, même si Java 9 n'a pas eu le succès fulgurant de Java 8, il a apporté des innovations radicales qui influencent encore notre utilisation du langage aujourd'hui. C’est presque de la science-fiction, quoi!
+Ash : Une révolution silencieuse, hein? [pause] Dis-m'en plus, quelles sont les gros changements qu'on doit remercier Java 9 pour?
+Alloy : Bien sûr! Tout d'abord, il y a la fameuse modularisation avec la JEP 261, qui, au passage, a un peu traumatisé les développeurs.
+Ash : Ah la la, les bons vieux souvenirs des systèmes modulaires... un cauchemar pour certains, une bénédiction pour peu d'autres! [rire]
+Alloy : Exactement! Et pour ceux qui avaient le courage de s'y plonger, c'était un vrai trésor pour structurer, sécuriser et optimiser ses applications. [emphasis] C’est surtout un super point pour les adeptes du Clean Architecture!
+Ash : Waouh, je ne savais pas que c'était si impactant. Mais il n'y avait pas que la modularisation, non?
+Alloy : Oui, il y avait aussi les JAR multi-releases! Des JAR capables de gérer plusieurs versions de Java dans un seul fichier. Super pratique, mais franchement... qui avait vraiment envie de jongler avec ça, hein?
+Ash : Exactement! Ça sonnait bien sur le papier, mais en pratique, c’était une autre histoire. [pause] Et sinon, est-ce qu'il y a des fonctionnalités plus "cool" dont on pourrait profiter?
+Alloy : Oh mais bien sûr! Le silenceux mais puissant [JEP 280: Indify String Concatenation], grâce auquel la JVM optimise la concaténation de chaînes à nous faire gagner en performance et en mémoire.
+Ash : Génial! Et pour ceux qui aiment les performances pointues, il y a toujours le fameux G1GC, le Garbage Collector que Java 9 a adopté par défaut. Dire qu'il fait tout ça sans nous déranger, ça c'est beau!
+Alloy : En plein dans le mille! Et je dois aussi mentionner les Compact Strings qui réduisent la consommation mémoire. Moins de mémoire utilisée, plus de vitesse. Qui ne voudrait pas de cela?
+Ash : Chaque morceau de mémoire compte! On dirait que Java 9 était plein de trésors cachés. [pauser] Tu crois qu’on pourrait l'apprécier bien plus si on osait l'explorer un peu plus?
+Alloy : [emphasis] Absolument Ash! Et ça me rappelle un petit dicton: "Ne pas juger un livre à sa couverture... ou une version de Java à sa réputation!" [rire]
+Ash : Belle conclusion! Merci de nous avoir fait redécouvrir Java 9 aujourd'hui. Et pour nos auditeurs, n'oubliez pas de jeter un œil sur ces fonctionnalités dans vos prochains projets! Bisous tech à vous tous!
+Alloy : Merci d’avoir été avec nous, et à la prochaine sur "Tech Talk with Alloy and Ash"! Bye bye!
+"""

src/script_generation.py

@@ -0,0 +1,126 @@
+from dataclasses import dataclass
+import os
+from langchain.chat_models import init_chat_model
+from langchain_core.prompts import PromptTemplate
+from pydantic import BaseModel, Field
+from mocked_script import mocked_raw_script
+@dataclass
+class ScriptConfig:
+    articles_path: str = "./articles"
+    model: str = "gpt-4o"
+    model_provider: str = "openai"
+    api_key: str = os.getenv("OPENAI_API_KEY", "")
+    mocked: bool = False
+
+
+class PodLine(BaseModel):
+    """Podcast line"""
+    speaker: str = Field(description="The name of the speaker")
+    text: str = Field(description="The text spoken by the speaker")
+
+# Pydantic
+class PodScript(BaseModel):
+    """Podcast script"""
+    conversation: list[PodLine] = Field(description="The setup of the joke")
+
+class MarkdownToScrip:
+    def __init__(self, config: ScriptConfig):
+        self._config = config
+        self._llm = init_chat_model(
+            model=config.model, 
+            model_provider=config.model_provider, 
+            api_key=config.api_key).with_structured_output(PodScript)
+        self._prompt = PromptTemplate.from_template( """You are a creative podcast scriptwriter specializing in tech content. Your task is to turn the following technical article into a spoken podcast script designed for two speakers
+            The goal is to create a clear, engaging, natural-sounding conversation that feels spontaneous but informative, as if recorded for a professional podcast. The tone should be friendly, curious, and energetic.
+            1. The podcast must feature two fictional hosts, **{speaker1_name}** and **{speaker2_name}**, who take turns discussing the content.
+            2. Add informal elements like light humor, reactions, rhetorical questions, and natural interjections (\"Wait, what?\", \"Exactly!\", \"That's wild\", etc.)
+            3. Emphasize key points or surprising facts by marking them with [pause], [emphasis], or *italicized phrases* to guide expressive TTS rendering.
+            4. Begin with a short intro to set the tone of the episode and end with a friendly closing.
+            5. Break the discussion into logical sections (e.g., introduction, main points, implications, etc.)
+            6. Keep the language conversational and oral (short sentences, contractions, and natural rhythm).
+            7. Keep the duration equivalent to approximately 3–4 minutes when read aloud.
+            8. {language_instruction}
+            Now write the full podcast script with style markers where relevant.
+                                               
+            Here is the article text:
+            {article}""")
+        
+
+    def _fetch_article(self, article: str) -> str:
+        """Fetches the article content from the specified path.
+        Args:
+            article (str): The name of the article file.
+        Returns:
+            str: The content of the article.
+        Raises:
+            ValueError: If the article is empty or not found.
+            FileNotFoundError: If the article file does not exist.
+        """
+        if not article:
+            raise ValueError("Article cannot be empty")
+
+        full_path = f"{self._config.articles_path}/{article}"
+        if not os.path.exists(full_path):
+            raise FileNotFoundError(f"Article not found: {full_path}")
+        with open(full_path, "r", encoding="utf-8") as file:
+            text = file.read()
+        if not text:
+            raise ValueError("Article content is empty")
+        return text
+
+    async def _generate_script(self, article: str, target_language, speaker1_name: str, speaker2_name: str) :
+        """Generates a podcast script from the given text using the LLM.
+        Args:
+            text (str): The input text to be converted into a podcast script.
+            target_language (str): The target language for the podcast.
+        Returns:
+            str: The generated podcast script in JSON format.
+        Raises:
+            ValueError: If the input text is empty or if the LLM request fails.
+        """
+        if target_language == "Auto Detect":
+            language_instruction = "The podcast MUST be in the same language as the article."
+        else:
+            language_instruction = f"The podcast MUST be in {target_language} language"
+
+        try:
+            response  = await self._prompt.pipe(self._llm).ainvoke(
+              {  "speaker1_name":speaker1_name,
+                "speaker2_name":speaker2_name,
+                "language_instruction":language_instruction,
+                "article":article}
+            )
+            if isinstance(response, PodScript):
+                return response 
+            elif isinstance(response, dict):
+                return PodScript(**response)
+        except Exception as e:
+                raise RuntimeError(f"Failed to generate podcast script: {e}")
+        
+    def _generate_mock_podcast_script(self) -> PodScript:
+        lines = []
+        for raw_line in mocked_raw_script.strip().splitlines():
+            if ':' in raw_line:
+                speaker, text = raw_line.split(':', 1)
+                lines.append(PodLine(speaker=speaker.strip(), text=text.strip()))
+        return PodScript(conversation=lines)
+    
+    async def run(self, article: str, target_language: str, speaker1_name: str, speaker2_name: str):
+        """Main method to convert an article to a podcast script.
+        Args:
+            article (str): The name of the article file.
+            target_language (str): The target language for the podcast.
+            speaker1_name (str): The name of the first speaker.
+            speaker2_name (str): The name of the second speaker.
+        Returns:
+            PodScript: The generated podcast script.
+        """
+        print("Running script generation")
+        if self._config.mocked:
+            return self._generate_mock_podcast_script()
+        else:
+            text = self._fetch_article(article)
+            return await self._generate_script(text, target_language, speaker1_name, speaker2_name)
+
+
+

src/streamlit_app.py

@@ -1,40 +1,179 @@
-import altair as alt
-import numpy as np
-import pandas as pd
 import streamlit as st
+import asyncio
+from dotenv import load_dotenv
+load_dotenv()
 
-"""
-# Welcome to Streamlit!
-
-Edit `/streamlit_app.py` to customize this app to your heart's desire :heart:.
-If you have any questions, checkout our [documentation](https://docs.streamlit.io) and [community
-forums](https://discuss.streamlit.io).
-
-In the meantime, below is an example of what you can do with just a few lines of code:
-"""
-
-num_points = st.slider("Number of points in spiral", 1, 10000, 1100)
-num_turns = st.slider("Number of turns in spiral", 1, 300, 31)
-
-indices = np.linspace(0, 1, num_points)
-theta = 2 * np.pi * num_turns * indices
-radius = indices
-
-x = radius * np.cos(theta)
-y = radius * np.sin(theta)
-
-df = pd.DataFrame({
-    "x": x,
-    "y": y,
-    "idx": indices,
-    "rand": np.random.randn(num_points),
-})
-
-st.altair_chart(alt.Chart(df, height=700, width=700)
-    .mark_point(filled=True)
-    .encode(
-        x=alt.X("x", axis=None),
-        y=alt.Y("y", axis=None),
-        color=alt.Color("idx", legend=None, scale=alt.Scale()),
-        size=alt.Size("rand", legend=None, scale=alt.Scale(range=[1, 150])),
-    ))
+from config import languages, voice_names, default_speaker_1, default_speaker_2, articles
+from script_generation import MarkdownToScrip, ScriptConfig, PodScript
+from audio_generation import ScriptToAudio, AudioConfig
+
+# Generators config
+script_config = ScriptConfig()
+audio_config = AudioConfig()
+# UI initial state
+for key in ["generation_started", "script_ready", "audio_ready", "pending_generation", "audio_generation_started"]:
+    st.session_state.setdefault(key, False)
+
+# Async helpers
+async def generate_script(article: str, language: str, voice1: str, voice2: str):
+    generator = MarkdownToScrip(script_config)
+    return await generator.run(article, language, voice1, voice2)
+
+async def generate_audio(script: PodScript, voice1: str, voice2: str):
+    generator = ScriptToAudio(audio_config)
+    return await generator.run(script, voice1, voice2)
+
+# Sync wrappers for Streamlit
+def generate_script_sync(article: str, language: str, voice1: str, voice2: str) -> PodScript | None:
+    return asyncio.run(generate_script(article, language, voice1, voice2))
+
+def generate_audio_sync(script: PodScript, voice1: str, voice2: str):
+    return asyncio.run(generate_audio(script,voice1, voice2))
+
+
+def render_form():
+    """Render the form for article selection and voice configuration."""
+    with st.form("generation_form"):
+        article = st.selectbox("Article", options=articles, format_func=lambda x: x[0])
+        language = st.selectbox("Langue de sortie", languages, index=0)
+        voice1 = st.selectbox("Voix Speaker 1", voice_names, index=default_speaker_1)
+        voice2 = st.selectbox("Voix Speaker 2", voice_names, index=default_speaker_2)
+
+        submitted = st.form_submit_button("📜 Générer le script")
+
+    if submitted:
+        st.session_state["generation_started"] = True
+        st.session_state["pending_generation"] = True
+        st.session_state["article"] = article[1]
+        st.session_state["language"] = language
+        st.session_state["voice1"] = voice1
+        st.session_state["voice2"] = voice2
+        st.rerun()
+
+
+def render_script_panel():
+    """Render the panel displaying the generated podcast script."""
+    st.markdown("### 🎧 Script du podcast")
+
+    podscript: PodScript = st.session_state["script"]
+    html = """
+        <div style='
+            height: 400px;
+            overflow-y: auto;
+            padding: 1em;
+            border: 1px solid #ccc;
+            border-radius: 8px;
+            margin-bottom: 1em;
+        '>
+        """
+    for line in podscript.conversation:
+        html += f"<p><strong>{line.speaker}</strong> : {line.text}</p>"
+    html += "</div>"
+
+    st.markdown(html, unsafe_allow_html=True)
+
+
+def render_audio_panel():
+    """Render the panel for audio generation and playback."""
+    is_generating = st.session_state.get("audio_generation_started", False)
+    is_done = st.session_state.get("audio_ready", False)
+
+    # Disable the button if already generating or done
+    generate_audio_disabled = is_generating or is_done
+
+    # Display the button to generate audio
+    col1, col2, col3 = st.columns([1, 2, 1])
+    with col2:
+        clicked = st.button("🎙️ Générer l'audio", key="generate_audio_btn", disabled=generate_audio_disabled)
+
+    if clicked:
+        st.session_state["audio_generation_started"] = True
+        st.rerun()
+
+    # Generate audio if not already done
+    if is_generating and not is_done:
+        with st.spinner("Génération de l’audio en cours...", show_time=True):
+            st.markdown("""
+            > Cela peut prendre un minute, merci de patienter 🙂.
+            """)
+            audio_path = generate_audio_sync(
+                st.session_state["script"],
+                st.session_state["voice1"],
+                st.session_state["voice2"],
+            )
+            st.session_state["audio_path"] = audio_path
+            st.session_state["audio_ready"] = True
+            st.session_state["audio_generation_started"] = False
+        st.rerun()
+
+    if is_done:
+        st.markdown("### 🔊 Podcast généré")
+        st.audio(st.session_state["audio_path"])
+
+def render_sidebar():
+    with st.sidebar:
+        st.title("🎙️ UpVoice")
+        st.markdown("Génèrez un podcast à partir d’un article tech")
+        content = """
+
+        * Pour le moment la génération est limitée à un podscast de ~3 minutes.
+
+        * L'audio est générée via [ gpt4o-mini-tts](https://platform.openai.com/docs/models/gpt-4o-mini-tts), d'autres modèles de génération seront bientôt proposés. 
+
+        * N'hésitez pas à visiter 👉 [Le Blog by Younup](https://www.younup.fr/blog) pour plus de contenu tech !.
+        """
+        st.markdown(f"""
+        <div style="
+            border: 1px solid rgba(250, 250, 250, 0.2);
+            border-radius: 10px;
+            padding: 1em;
+            box-shadow: 1px 1px 5px rgba(0,0,0,0.05);
+            margin-bottom: 1em;
+        ">
+            <p style="margin: 0;">{content}</p>
+        </div>
+        """, unsafe_allow_html=True)
+
+
+        # Reset
+        if st.session_state["generation_started"]:
+            if st.button("🔄 Nouvelle génération"):
+                for key in ["generation_started", "script_ready", "audio_ready", "pending_generation", "script", "audio_path", "audio_generation_started"]:
+                    st.session_state.pop(key, None)
+                st.rerun()
+
+def main():
+    st.set_page_config(page_title="UpVoice 🎙️", layout="wide")
+    render_sidebar()
+
+    # Affiche formulaire si aucune génération encore
+    if not st.session_state["generation_started"]:
+        render_form()
+
+    # Si soumission validée, mais script pas encore généré
+    if st.session_state.get("pending_generation"):
+        with st.spinner("Génération du script en cours...", show_time=True):
+            st.markdown("""
+            > Cela peut prendre une trentaine de seconde, merci de patienter 🙂.
+            """)
+            st.session_state["script"] = generate_script_sync(
+                st.session_state["article"],
+                st.session_state["language"],
+                st.session_state["voice1"],
+                st.session_state["voice2"]
+            )   
+            st.session_state["script_ready"] = True
+            st.session_state["pending_generation"] = False
+        st.rerun()
+
+    # Affichage script et bouton audio
+    if st.session_state.get("script_ready"):
+        col1, col2 = st.columns([1, 1])
+        with col1:
+            render_script_panel()
+        with col2:
+            render_audio_panel()
+
+
+if __name__ == "__main__":
+    main()