i18n(french): sync Anchor Flash Loan challenge

Author: dhl

src/app/content/challenges/anchor-escrow/fr/pages/make.mdx

@@ -142,7 +142,6 @@ Ici, nous ajoutons deux contrôles de validation. Un sur l'argument `amount` et
 
 Certaines extensions de SPL Token-2022, par exemple les hooks de transfert, les transferts confidentiels, les états de compte par défaut, peuvent introduire des vulnérabilités telles que le blocage des transferts, le verrouillage des fonds et provoquer des rug pulls dans la logique des escrows, des vaults ou des CPIs.
 
-
 - Assurez-vous que `mint_a` et `mint_b` appartiennent au même programme de jetons afin d'éviter les échecs de CPI.
 - Utilisez des jetons correctement audités (par exemple, USDC, wSOL) issus du programme standard SPL-Token.
 - Évitez les mints de Token-2022 non vérifiées ou complexes.

src/app/content/challenges/anchor-flash-loan/fr/challenge.mdx

@@ -2,6 +2,8 @@ import { ArticleSection } from "../../../../components/ArticleSection/ArticleSec
 
 # Prêt Flash avec Anchor
 
+![Anchor Flash Loan](/graphics/challenge-banners/anchor-flash-loan.png)
+
 L'introspection des instructions est une fonctionnalité puissante qui permet à un programme d'examiner et d'analyser d'autres instructions au sein de la même transactions. Cela inclut les instructions qui n'ont pas encore été exécutées, donnant à votre programme la possibilité de "regarder dans le futur" et de prendre des décisions basées sur ce qui se passera plus tard dans la transaction.
 
 C'est un peu comme si vous aviez une vision à rayons X pour les transactions : votre programme peut voir l'ensemble de la transaction pour comprendre la séquence complète des opérations avant de décider de la marche à suivre.

src/app/content/challenges/anchor-flash-loan/fr/pages/borrow.mdx

@@ -42,7 +42,6 @@ Vient maintenant la partie critique de la sécurité : l'utilisation de l'intros
 
 Nous commençons par accéder au sysvar `instructions` qui contient les informations sur toutes les instructions de la transaction actuelle :
 
-
 ```rust
 /*
     Instruction Introspection
@@ -56,6 +55,7 @@ let ixs = ctx.accounts.instructions.to_account_info();
 
 Enfin, nous effectuons la vérification la plus critique : nous nous assurons que la dernière instruction de la transaction est une instruction de remboursement valide :
 - Nous commençons par vérifier le nombre d'instructions et nous nous assurons que nous chargeons la dernière instruction de la transaction
+- Ensuite, nous vérifions le nombre d'instructions et nous assurons que nous chargeons la dernière instruction de la transaction
 - TNous vérifions ensuite qu'il s'agit bien de l'instruction de remboursement en vérifiant l'ID du programme et le discriminateur de l'instruction
 - Nous terminons en vérifiant que les ATAs passés dans l'instruction de remboursement sont les mêmes que ceux que nous passons dans notre instruction `Borrow`
 
@@ -66,6 +66,10 @@ Enfin, nous effectuons la vérification la plus critique : nous nous assurons qu
     Make sure that the last instruction of this transaction is a repay instruction
 */
 
+// Check if this is the first instruction in the transaction.
+let current_index = load_current_index_checked(&ctx.accounts.sysvar_instructions)?;
+require_eq!(current_index, 0, ProtocolError::InvalidIx); 
+
 // Check how many instruction we have in this transaction
 let instruction_sysvar = ixs.try_borrow_data()?;
 let len = u16::from_le_bytes(instruction_sysvar[0..2].try_into().unwrap());

src/app/content/challenges/anchor-flash-loan/fr/verify.mdx

@@ -15,4 +15,3 @@ Maintenant, mettez en pratique ce que vous avez appris. Créez un programme de p
     Votre programme doit vérifier le `borrowed_amount` à la fin de la transaction et rembourser le protocole avec le montant correct.
   </Requirement>
 </RequirementList>
-

src/app/content/challenges/assembly-timeout/fr/challenge.mdx

@@ -71,7 +71,7 @@ call sol_get_clock_sysvar
 ldxdw r1, [r1+0x0000]
 ```
 
-L'appel système `sol_get_clock_sysvar` écrit les données actuelles de `Clock` dans `r1`. 
+L'appel système `sol_get_clock_sysvar` écrit les données `Clock` actuelles à l'adresse mémoire spécifiée dans `r1`.
 
 Comme la structure Clock fait 40 octets (trop grande pour les registres qui ne contiennent que 8 octets chacun), nous utilisons la pile pour un stockage rapide sans allocation avec nettoyage automatique.
 

src/app/content/challenges/assembly-timeout/fr/verify.mdx

@@ -12,7 +12,7 @@ Créez un programme qui n'a qu'une seule instruction. Il doit :
 - Utiliser les 8 premiers octets du compte `Clock` pour récupérer le slot actuel.
 - Vérifier si le slot actuel est supérieur au slot passé dans l'instruction. Si c'est le cas, renvoyer le code d'erreur 1.
 
-> Pour obtenir le bon décalage des données d'instruction, vous pouvez utiliser notre [outil](https://sbpf.xyz). N'oubliez pas d'ajouter un compte et de définir sa longueur de données à 40 !
+> Pour obtenir le bon décalage des données d'instruction, vous pouvez utiliser notre [outil](https://sbpf.xyz). N'oubliez pas d'ajouter un compte et de définir sa longueur de données à 40 ! 
 
 Commencez par installer le package sBPF comme expliqué dans la [section outillage](/en/courses/introduction-to-assembly/tooling) du cours Introduction à l'Assembly et compilez votre programme en utilisant la commande suivante dans votre terminal :
 

src/app/content/challenges/pinocchio-amm/fr/challenge.mdx

@@ -1,3 +1,5 @@
+import ArticleSection from "../../../../components/ArticleSection/ArticleSection";
+
 ![Pinocchio Amm Challenge](/graphics/challenge-banners/pinocchio-amm.png)
 
 # L'Amm
@@ -48,7 +50,7 @@ Au cœur de la plupart des AMM se trouve une formule simple mais puissante connu
 
 ### La formule
 
-La formule AMM la plus courante est : `x * y = k` où : 
+La formule AMM la plus courante est : `x * y = k` où :
 - `x` = quantité de jetons X dans la *pool*
 - `y` = quantité de jetons Y dans la *pool*
 - `k` = une constante (ne change jamais)
@@ -59,7 +61,7 @@ Chaque fois qu'une personne échange un jeton contre un autre, la *pool* ajuste
 
 Supposons que la *pool* commence avec 100 jetons X et 100 jetons Y : `100 * 100 = 10,000`.
 
-Si un utilisateur souhaite échanger 10 jetons X contre des jetons Y, la *pool* doit conserver `k = 10,000`. Donc, si `x_new` = 110 (après le dépôt), on résout `y_new`: `110 * y_new = 10,000` donc `y_new = 10,000 / 110 ≈ 90.91`. 
+Si un utilisateur souhaite échanger 10 jetons X contre des jetons Y, la *pool* doit conserver `k = 10,000`. Donc, si `x_new` = 110 (après le dépôt), on résout `y_new`: `110 * y_new = 10,000` donc `y_new = 10,000 / 110 ≈ 90.91`.
 
 L'utilisateur recevra `100 - 90.91 = 9.09` jetons Y (moins les frais éventuels).
 
@@ -69,7 +71,7 @@ Lorsque des utilisateurs déposent les deux jetons dans la *pool*, ils deviennen
 - Les jetons LP sont émis proportionnellement à la quantité de liquidités que vous ajoutez.
 - Lorsque vous effectuez un retrait, vous brûlez vos jetons LP afin de récupérer votre part des deux jetons (plus une part des frais perçus sur les échanges).
 
-Le premier fournisseur de liquidités fixe le ratio initial. Par exemple, si vous déposez 100 X et 100 Y, vous pourriez recevoir 100 jetons LP. 
+Le premier fournisseur de liquidités fixe le ratio initial. Par exemple, si vous déposez 100 X et 100 Y, vous pourriez recevoir 100 jetons LP.
 
 Ensuite, si la *pool* contient déjà 100 X et 100 Y, et que vous ajoutez 10 X et 10 Y, vous obtenez des jetons LP proportionnels à votre contribution : `share = deposit_x / total_x = 10 / 100 = 10%` donc l'Amm créera dans le portefeuille de l'utilisateur 10 % du total de l'offre du LP.
 
@@ -174,7 +176,7 @@ L'attribut `#[repr(C)]` garantit que notre structure dispose d'une disposition m
 Nous stockons `seed` (u64) et `fee` (u16) sous forme de tableaux d'octets plutôt que sous leur type natif afin de garantir une désérialisation sûre. Lorsque les données sont lues à partir du compte, il n'y a aucune garantie quant à l'alignement de la mémoire, et la lecture d'un `u64` à partir d'une adresse mémoire non alignée est un comportement indéfini. En utilisant des tableaux d'octets et en effectuant la conversion avec `from_le_bytes()`, nous garantissons que les données peuvent être lues en toute sécurité, quel que soit leur alignement, tout en assurant un ordre des octets *little-endian* cohérent sur toutes les plateformes.
 
 Chaque champ de la structure `Config` a une fonction spécifique :
-- **state**: Suit l'état actuel de l'AMM (par exemple, non initialisé (*uninitialized*), initialisé (*initialized*), désactivé (*disabled*), ou retrait uniquement (*withdraw-only*)). 
+- **state**: Suit l'état actuel de l'AMM (par exemple, non initialisé (*uninitialized*), initialisé (*initialized*), désactivé (*disabled*), ou retrait uniquement (*withdraw-only*)).
 - **seed**: Une valeur unique utilisée pour la génération d'Adresse Dérivées de Programme (PDA), permettant à plusieurs AMM d'exister avec différentes configurations.
 - **authority**: La clé publique avec contrôle administratif sur l'AMM (par exemple, pour mettre en pause ou mettre à jour la *pool*). Peut être défini comme immutable en passant `[0u8; 32]`.
 - **mint_x**: L'adresse de mint du jeton SPL pour le jeton X de la *pool*.

src/app/content/challenges/pinocchio-amm/fr/pages/initialize.mdx

@@ -15,6 +15,7 @@ Voici les comptes nécessaires pour ce contexte :
 - `system` et `token` programs: Comptes de programme requis pour initialiser les comptes ci-dessus. Doit être `executable`.
 
 > Avec l'expérience, vous remarquerez que bon nombre de ces vérifications peuvent être omises en vous appuyant plutôt sur les contraintes imposées par les CPI eux-mêmes. Par exemple, pour cette structure de compte, aucun contrôle explicite n'est nécessaire. En effet, si les contraintes ne sont pas respectées, le programme échouera par défaut. Je soulignerai ces nuances au fur et à mesure que nous avancerons dans la logique.
+
 Comme il n'y a pas beaucoup de changements par rapport à la structure habituelle que nous créons, je vous laisse le soin de l'implémentation :
 
 ```rust
@@ -47,6 +48,7 @@ Voici les données d'instruction que nous devons transmettre :
 - `authority`: La clé publique qui aura l'autorité administrative sur l'AMM. Si elle n'est pas fournie, la *pool* peut être définie comme immuable. Doit être un `[u8; 32]`
 
 > Comme vous pouvez le constater, plusieurs de ces champs pourraient être dérivés différemment. Par exemple, nous pourrions obtenir le `mint_x` en passant le compte de `Mint` et en le lisant directement ou générer la valeur `bump` dans le programme. Cependant, en les passant explicitement, nous visons à créer le programme le plus optimisé et le plus efficace possible.
+
 Dans cette implémentation, nous traitons le parsing des données d'instruction de manière plus flexible et à un niveau plus bas que d'habitude. C'est pourquoi nous allons expliquer les raisons qui nous poussent à prendre les décisions suivantes :
 
 ```rust
@@ -113,7 +115,7 @@ let config_seeds = [
 ];
 ```
 - Remplissez le compte `Config` en le chargeant à l'aide de `Config::load_mut_unchecked()` puis en le remplissant avec toutes les données nécessaires à l'aide de l'aide `config.set_inner()`.
-- Créez le compte de `Mint` pour la LP à l'aide des instructions `CreateAccount` et `InitializeMint2` et des *seeds* suivantes : 
+- Créez le compte de `Mint` pour la LP à l'aide des instructions `CreateAccount` et `InitializeMint2` et des *seeds* suivantes :
 ```rust
 let mint_lp_seeds = [
     Seed::from(b"mint_lp"),
@@ -123,6 +125,7 @@ let mint_lp_seeds = [
 ```
 
 > La `mint_authority` de `mint_lp` est le compte `config`
+
 Vous devriez être suffisamment compétent pour le faire vous-même, je vous laisse donc le soin de l'implémenter :
 
 ```rust

src/app/content/challenges/pinocchio-escrow/fr/challenge.mdx

@@ -1,10 +1,12 @@
-![Pinocchio Escrow Challenge](/graphics/challenge-banners/pinocchio-escrow.png)
+import ArticleSection from "../../../../components/ArticleSection/ArticleSection";
 
 # L'Escrow
 
+![Pinocchio Escrow Challenge](/graphics/challenge-banners/pinocchio-escrow.png)
+
 Un *escrow* est un outil financier puissant qui permet des échanges sécurisés de jetons entre deux parties.
 
-Imaginez un coffre-fort numérique où un utilisateur peut bloquer un jeton A en attendant qu'un autre utilisateur dépose un jeton B avant que l'échange ne soit terminé. 
+Imaginez un coffre-fort numérique où un utilisateur peut bloquer un jeton A en attendant qu'un autre utilisateur dépose un jeton B avant que l'échange ne soit terminé.
 
 Cela crée un environnement sans confiance où aucune des parties n'a à craindre que l'autre ne revienne sur sa décision.
 
@@ -124,10 +126,10 @@ Examinons maintenant l'implémentation et toutes ses fonctions d'aide :
 
 ```rust
 impl Escrow {
-    pub const LEN: usize = size_of::<u64>() 
-    + size_of::<Pubkey>() 
-    + size_of::<Pubkey>() 
-    + size_of::<Pubkey>() 
+    pub const LEN: usize = size_of::<u64>()
+    + size_of::<Pubkey>()
+    + size_of::<Pubkey>()
+    + size_of::<Pubkey>()
     + size_of::<u64>()
     + size_of::<[u8;1]>();
 

src/app/content/challenges/pinocchio-escrow/fr/pages/make.mdx

@@ -18,7 +18,7 @@ Voici les comptes dont le contexte a besoin :
 - system_program: le programme système. Doit être executable
 - token_program: le programme de jeton. Doit être executable
 
-**Remarque** : Nous allons utiliser les types introduits dans l'[Introduction à Pinocchio](/en/courses/introduction-to-pinocchio/pinocchio-accounts).
+**Remarque** : Nous allons utiliser les assistants que nous avons présentés dans l'[Introduction à Pinocchio](/en/courses/introduction-to-pinocchio/pinocchio-accounts).
 
 Cela se présente donc ainsi :