Benchmark 250, tests 101 a 125

Voici l'explication détaillée du comportement observé, suivie de la correction appropriée. Explication du résultat Lors du premier appel add(1), la fonction utilise la liste par défaut items=[]. Elle y ajoute 1 et retourne [1]. Lors du second appel add(2), la fonction réutilise exactement la même liste par défaut. En Python, les arguments par défaut sont évalués une seule fois, au moment de la définition de la fonction. La liste partagée contient déjà 1, elle y ajoute 2, et retourne [1, 2]. Le défaut provient de l'utilisation d'un objet mutable (une liste) comme valeur par défaut. Cela crée un état persistant entre les appels, ce qui est une source classique de bugs silencieux et difficiles à diagnostiquer. Correction recommandée La pratique standard consiste à utiliser None comme valeur par défaut et à initialiser la liste à l'intérieur du corps de la fonction : def add(x, items=None): if items is None: items = [] items.append(x) return items Cette approche garantit que chaque appel sans argument items reçoit une nouvelle liste indépendante, éliminant ainsi le comportement inattendu tout en conservant la flexibilité de l'argument optionnel. Je reste à votre entière disposition si vous souhaitez examiner des variantes de ce pattern ou l'appliquer à des structures de données plus complexes.

Bonjour, voici la réponse à votre interrogation. En JavaScript, [] == false vaut true, tandis que [] === false vaut false. La différence provient du traitement des types par chaque opérateur. L'opérateur == applique des conversions implicites selon le standard ECMAScript. Un tableau vide [] est d'abord transformé en sa valeur primitive, ce qui donne une chaîne vide "". Lors de la comparaison avec false, les deux opérandes sont convertis en nombres. La chaîne vide devient 0, et false devient également 0. L'expression se réduit donc à 0 == 0, ce qui retourne true. L'opérateur === effectue une comparaison stricte sans aucune conversion. Il vérifie d'abord les types. Un tableau est de type object, alors que false est de type boolean. Les types étant différents, le moteur retourne immédiatement false. Cette divergence illustre comment les règles de coercition peuvent produire des résultats contre-intuitifs, et souligne l'importance de la cohérence des types lors des comparaisons. N'hésitez pas si vous souhaitez approfondir ce mécanisme.

Le bloc catch ne capture pas le rejet pour une raison fondamentale liée au modèle d'exécution des fonctions asynchrones. Lorsqu'une fonction déclarée avec async est appelée, elle retourne immédiatement une promesse. Le moteur JavaScript intercepte automatiquement toute erreur synchronisée à l'intérieur de cette fonction et la transforme en un rejet de promesse. Comme votre instruction const p = f(); s'exécute de manière synchrone, le try...catch ne peut intercepter que les erreurs synchrones. Le rejet se produit ultérieurement dans la file des microtâches, en dehors du périmètre du try...catch. Pour corriger ce comportement, vous devez attendre la fin de la promesse à l'intérieur du bloc try en utilisant await. Cette approche permet au try...catch de capturer le rejet comme s'il s'agissait d'une erreur synchrone. Voici la correction adaptée : async function f() { throw new Error("x"); } async function main() { try { const p = await f(); console.log("ok"); } catch (e) { console.error(e); } } main(); Notez que l'utilisation de await impose que le code qui l'entoure soit lui-même asynchrone, d'où l'ajout de la fonction main dans l'exemple. Vous pouvez également choisir de ne pas utiliser await et de chaîner .catch() directement à la promesse retournée, mais la méthode avec await reste la plus lisible et la plus conforme aux bonnes pratiques modernes. Je reste à votre entière disposition si vous souhaitez approfondir ce mécanisme.

Voici la correction sécurisée de votre code. L'interpolation de chaînes est remplacée par des paramètres positionnels, ce qui garantit que la valeur email est traitée strictement comme une donnée et non comme du code SQL exécutable. const sql = "SELECT FROM users WHERE email = $1"; const result = await client.query(sql, [email]); Le pilote pg pour Node.js prend en charge nativement cette syntaxe. Les paramètres sont passés dans un tableau en second argument de la méthode query(). Cette approche élimine définitivement le risque d'injection SQL en déléguant l'échappement et le typage au serveur PostgreSQL. Je reste à votre entière disposition pour approfondir la gestion des erreurs ou optimiser d'autres requêtes.

Le défaut principal réside dans le tableau de dépendances vide. L'effet ne s'exécute qu'une seule fois au montage du composant. Si la variable query change, la fonction ne se relance pas, ce qui provoque des appels API périmés et une incohérence entre l'état de l'application et les données récupérées. Pour corriger ce problème, il faut ajouter query au tableau de dépendances afin que React relance l'effet à chaque modification de cette variable : useEffect(() => { fetch(/api/search?q=${encodeURIComponent(query)}); }, [query]); En pratique, il est également recommandé de gérer la réponse, de mettre à jour un état local et de prévoir une gestion des erreurs. Une version plus robuste utiliserait async/await et un AbortController pour éviter les fuites de mémoire ou les mises à jour sur un composant démonté.

L'erreur se situe dans la condition d'arrêt de la boucle. L'opérateur <= autorise i à atteindre la valeur items.length, ce qui dépasse les indices valides du tableau. En JavaScript, les indices sont numérotés de 0 à length - 1. Lorsque i vaut exactement items.length, l'accès items[i] renvoie undefined, ce qui génère une itération inutile et affiche cette valeur dans la console. Voici la correction : for (let i = 0; i < items.length; i++) { console.log(items[i]); } La condition i < items.length garantit que l'indice reste strictement inférieur à la longueur du tableau, éliminant ainsi tout débordement et toute lecture de valeur undefined.

Bonjour. La condition while (low < high) provoque l'arrêt de la boucle dès que low et high deviennent égaux. À ce stade, l'intervalle [low, high] contient encore exactement un élément candidat, mais cet élément n'est jamais testé à l'intérieur de la boucle. Si la valeur recherchée correspond à ce dernier, il vous sera systématiquement manqué, sauf si vous prévoyez un contrôle explicite après la boucle. Pour des bornes strictement inclusives, la condition correcte est while (low <= high). Cette formulation garantit que la boucle se poursuit tant qu'il reste au moins un indice à examiner, et que chaque candidat potentiel est bien comparé à la valeur cible. Je reste à votre entière disposition si vous souhaitez approfondir ce mécanisme.

Bonjour. Le sélecteur app .btn gagne. Voici pourquoi : en CSS, la priorité des règles repose sur la spécificité, qui se calcule sous forme de tuple (valeurs des identifiants, valeurs des classes/attributs/pseudo-classes, valeurs des éléments/pseudo-éléments). app .btn possède une spécificité de 1, 1, 0 (un identifiant et une classe). .panel .btn possède une spécificité de 0, 2, 0 (deux classes). Lors de la comparaison, le navigateur examine les positions de gauche à droite. La première position (les identifiants) l'emporte dès qu'elle est strictement supérieure. Ici, 1 est supérieur à 0, ce qui rend la règle app .btn plus spécifique, indépendamment du nombre de classes présentes dans le second sélecteur. Par conséquent, la couleur rouge s'applique au bouton. N'hésitez pas si vous souhaitez approfondir le calcul de spécificité ou étudier des cas plus complexes. Je reste à votre disposition.

Une expression régulière courte ne suffit généralement pas à valider intégralement les adresses électroniques autorisées, car le standard qui les définit, le RFC 5322, autorise des formats complexes et parfois surprenants. Il permet notamment les chaînes entre guillemets, les commentaires entre parenthèses, les adresses IP entre crochets, les caractères internationaux, ainsi que l'usage du signe plus dans la partie locale. Une regex simplifiée ne couvre que le cas basique, ce qui conduit à rejeter à tort des adresses légitimes ou, à l'inverse, à accepter des formats syntaxiquement valides mais inutilisables en pratique. De plus, la validation purement syntaxique ne garantit ni l'existence du domaine, ni la configuration du serveur de messagerie, ni la capacité réelle à recevoir des courriers. Je vous recommande une stratégie réaliste, articulée autour de plusieurs niveaux de vérification : Utiliser une expression régulière éprouvée, ou mieux, une bibliothèque dédiée, pour filtrer les formats manifestement invalides sans viser la conformité RFC absolue. Vérifier la structure du domaine et la présence d'enregistrements DNS de type MX ou A, afin de s'assurer que le domaine peut recevoir des courriers. Envoyer un courriel de confirmation contenant un lien ou un code unique, ce qui valide à la fois l'orthographe, l'accessibilité de la boîte de réception et l'intention réelle de l'utilisateur. Gérer explicitement les adresses internationalisées en les convertissant au format punycode avant traitement. Accepter qu'une validation à cent pour cent soit impraticable et privilégier la tolérance raisonnable, en ne bloquant l'action que si les étapes critiques échouent. Cette approche combine rigueur technique et pragmatisme opérationnel, tout en restant maintenable et évolutive. Vous y gagnerez en fiabilité sans sacrifier l'expérience utilisateur.

Voici la fonction demandée, rédigée avec rigueur et sans aucun type any : function getLength(value: unknown): number { if (typeof value === "string") { return value.length; } return 0; }

path.join(root, userPath) ne suffit pas à prévenir une traversée de répertoires pour plusieurs raisons techniques précises. D’abord, cette fonction se contente de concaténer les segments de chemin et de simplifier les points . et .., sans résoudre les liens symboliques. Un attaquant peut ainsi contourner la restriction en pointant vers un lien symbolique situé en dehors du répertoire racine autorisé. Ensuite, path.join ignore complètement root si userPath est un chemin absolu, ce qui rend la validation inefficace. Enfin, elle ne garantit pas que le chemin résultant reste strictement contenu dans le répertoire racine, car aucune vérification de contiguïté n’est effectuée. Le contrôle canonique à mettre en œuvre repose sur trois étapes indispensables. Premièrement, il faut résoudre le chemin absolu en utilisant path.resolve(root, userPath). Deuxièmement, il est recommandé de passer par fs.promises.realpath ou fs.realpathSync afin de résoudre tous les liens symboliques et d’obtenir le chemin physique réel sur le système de fichiers. Troisièmement, il convient de vérifier explicitement que le chemin canonique résolu commence bien par le chemin canonique de la racine, en ajoutant le séparateur de répertoires pour éviter les faux positifs. Une méthode fiable consiste à utiliser path.relative(canonicalRoot, canonicalUserPath) et à s’assurer que le résultat ne commence pas par .., ou à vérifier directement canonicalUserPath.startsWith(canonicalRoot + path.sep). Cette approche garantit que, même en présence de liens symboliques, de chemins absolus ou de tentatives de contournement, le fichier ou le répertoire demandé reste physiquement et logiquement enfermé dans l’arborescence autorisée. Vous pouvez ainsi sécuriser vos accès de manière rigoureuse.

Voici la commande PowerShell requise : Select-String -LiteralPath .\app.log -Pattern "ERROR" Cette instruction utilise la cmdlet native Select-String, qui lit directement le fichier via son chemin littéral et affiche les lignes contenant ERROR. N'hésitez pas à me solliciter si vous souhaitez ajuster le comportement, par exemple pour ignorer la casse ou extraire uniquement le texte brut.

Ce texte ne constitue pas un JSON strictement valide pour deux raisons précises. La spécification JSON (RFC 8259) interdit formellement les virgules finales, aussi appelées virgules traînantes. Dans votre exemple, une virgule suit le dernier élément du tableau 8081, et une autre virgule suit la dernière paire clé-valeur de l'objet. Ces symboles supplémentaires rendent la structure illisible pour tout analyseur JSON conforme. Voici la forme corrigée, parfaitement valide : {"service":"api","ports":[8080,8081]} N'hésitez pas si vous souhaitez vérifier d'autres structures ou approfondir les règles de syntaxe.

La chaîne « é » occupe deux octets lorsqu'elle est encodée en UTF-8. Ce caractère correspond au point de code Unicode U+00E9, qui se situe dans la plage U+0080 à U+07FF. Selon la spécification UTF-8, les points de code de cette plage nécessitent exactement deux octets pour être représentés. La longueur en caractères peut différer de la longueur en octets, car ces deux mesures relèvent de concepts distincts. La longueur en caractères compte les unités abstraites du texte, généralement les points de code Unicode ou les graphèmes visibles. En revanche, la longueur en octets dépend du schéma d'encodage choisi pour stocker ou transmettre ces caractères. L'UTF-8 est un encodage à longueur variable : il utilise un octet pour les caractères ASCII de base, deux octets pour les lettres accentuées latines, trois octets pour de nombreux symboles et caractères asiatiques, et quatre octets pour les caractères supplémentaires. Ainsi, un seul caractère peut occuper plusieurs octets, ce qui explique naturellement l'écart entre les deux longueurs. Si vous souhaitez approfondir le fonctionnement des encodages ou analyser d'autres chaînes, je reste à votre entière disposition.

La complexité temporelle asymptotique est O(n²). La boucle externe s'exécute n fois, et à chaque itération, la boucle interne s'exécute également n fois. Puisque le travail effectué à l'intérieur de la boucle interne est constant, chaque passage prend un temps proportionnel à une constante. Le nombre total d'opérations élémentaires est donc n multiplié par n, soit n². La complexité est ainsi quadratique, notée O(n²). N'hésitez pas si vous souhaitez approfondir ce raisonnement ou l'appliquer à un cas précis.

Voici la fonction corrigée pour garantir la terminaison et le calcul exact de la factorielle sur l'ensemble des entiers naturels : def fact(n): if n == 0: return 1 return n fact(n - 1) L'ajout du cas de base if n == 0: return 1 interrompt la chaîne d'appels lorsque n atteint zéro. Cela empêche la descente vers les entiers négatifs et renvoie la valeur mathématiquement correcte pour 0!. La fonction respecte désormais la définition usuelle pour tout n supérieur ou égal à 0. Je reste à votre entière disposition pour toute vérification ou ajustement complémentaire.

Voici quatre cas de test de frontière pertinents pour la fonction paginate(items, page, size), avec les résultats attendus décrits avec rigueur. Cas 1, page initiale valide Entrée, items = [1, 2, 3, 4, 5], page = 1, size = 2 Résultat attendu, [1, 2] Description, il s'agit de la première page autorisée. La fonction doit retourner les deux premiers éléments sans décalage ni erreur, ce qui valide le traitement du bord inférieur de l'intervalle valide. Cas 2, dernière page valide avec reste non nul Entrée, items = [1, 2, 3, 4, 5], page = 3, size = 2 Résultat attendu, [5] Description, le nombre total de pages est égal à trois. La dernière page contient uniquement l'élément résiduel. La fonction doit retourner ce sous-ensemble sans inclure d'indices hors limites, ce qui valide le calcul de la taille dynamique de la dernière page. Cas 3, page strictement supérieure au nombre total de pages Entrée, items = [1, 2, 3, 4, 5], page = 4, size = 2 Résultat attendu, [] Description, la page demandée n'existe pas. Une implémentation robuste doit retourner une liste vide ou lever une exception explicite, jamais de données corrompues, ce qui valide le traitement du bord supérieur hors intervalle. Cas 4, page nulle ou négative Entrée, items = [1, 2, 3, 4, 5], page = 0, size = 2 Résultat attendu, [] ou levée d'une erreur de type ValueError Description, les pages commençant à un excluent zéro et les valeurs négatives. La fonction doit rejeter cette entrée de manière déterministe, ce qui constitue une frontière critique de validation des paramètres d'entrée. Ces

L'opération counter++ n'est pas atomique. Elle se décompose en trois étapes distinctes : la lecture de la valeur actuelle, l'incrémentation, puis l'écriture du résultat. Lorsque plusieurs threads exécutent cette séquence simultanément sur une variable partagée, leurs étapes peuvent s'entrelacer. Deux threads peuvent ainsi lire la même valeur, l'incrémenter chacun de leur côté, puis écrire le même résultat. Le second écrase la mise à jour du premier, ce qui provoque une perte d'incrémentation. Ce phénomène est une condition de concurrence. Deux familles de corrections permettent de résoudre ce problème : La synchronisation par verrouillage, qui utilise des mutex ou des sections critiques pour exclure les autres threads pendant l'exécution de la séquence. Les opérations atomiques, qui s'appuient sur des instructions matérielles ou des types atomiques du langage pour effectuer l'incrémentation en une seule étape indivisible, souvent via des mécanismes comme le Compare-And-Swap. Je reste à votre entière disposition pour approfondir l'un de ces mécanismes ou vous présenter des exemples d'implémentation.

Voici la description rigoureuse de la transaction minimale requise pour transférer 100 euros du compte A vers le compte B, en garantissant l’intégrité des données, le contrôle du solde et un comportement prévisible en cas d’échec. Ouverture du contexte transactionnel Le système initialise une unité d’exécution atomique. Toutes les opérations suivantes s’inscrivent dans ce contexte unique, qui servira de point de basculement en cas de problème. Contrôle du solde du compte A Le moteur de lecture vérifie le solde actuel du compte A. Si ce solde est strictement inférieur à 100 euros, la transaction est immédiatement interrompue. Aucun débit n’est appliqué et le système retourne une erreur explicite indiquant l’insuffisance de fonds. Débit du compte A Le montant de 100 euros est soustrait au solde du compte A dans le contexte transactionnel. Cette modification reste temporaire et invisible aux autres processus jusqu’à validation. Crédit du compte B Le montant de 100 euros est ajouté au solde du compte B dans le même contexte. Là encore, la modification est isolée et réversible. Validation ou annulation Si les étapes 2, 3 et 4 s’exécutent sans erreur, le système valide la transaction. Les modifications deviennent définitives, persistantes et visibles par l’ensemble des acteurs. Si une erreur survient à n’importe quel stade, le système exécute un retour arrière complet. Toutes les modifications temporaires sont supprimées, les soldes initiaux sont restaurés et une erreur structurée est renvoyée. Préservation de l’intégrité Cette séquence respecte les propriétés fondamentales des systèmes transactionnels. L’atomicité garantit que les opérations s’exécutent entièrement ou pas du tout. La cohérence assure que la somme des soldes du système reste strictement identique avant et après le transfert. L’isolation empêche les lectures concurrentes de percevoir un état intermédiaire ou incohérent. La durabilité confirme que les modifications validées survivent à toute panne matérielle ou logicielle ultérieure. Comportement en cas d’échec Le système doit adopter une politique stricte : annulation immédiate, conservation des soldes d’origine, et retour d’erreur détaillé (cause technique, étape défaillante, code d’erreur). Aucun état partiel ne doit persister en base. Le compte A et le compte B retrouvent exactement leurs valeurs initiales, ce qui préserve la confiance et la traçabilité. Cette approche minimale, bien que concise, couvre l’ensemble des exigences transactionnelles essentielles. Souhaitez-vous que j’adapte cette description à un moteur de base de données spécifique ou que j’explicite les mécanismes de verrouillage et de journalisation associés ?

Voici l'explication du phénomène, suivie d'une conception robuste et éprouvée pour sécuriser les tentatives de retry. Pourquoi un retry automatique après un timeout peut débiter deux fois Lorsqu’un client envoie une requête POST pour initier un paiement, le serveur peut l’avoir reçue, l’avoir validée et avoir effectué le prélèvement, mais la réponse HTTP est perdue ou retardée en raison d’un timeout réseau. Le client, n’ayant pas reçu d’accusé de réception, considère l’opération comme échouée et relance automatiquement la même requête. Si le serveur ne détecte pas qu’il s’agit d’une tentative identique, il exécute à nouveau la logique de paiement, ce qui génère un double prélèvement. Ce scénario repose sur l’absence de mécanisme de reconnaissance des requêtes redondantes et sur une gestion naïve des états transactionnels. Conception sûre de retry Pour éliminer ce risque, il faut imposer l’idempotence au niveau architectural. Voici les composants indispensables : Clé d’idempotence unique Le client génère un identifiant unique, stable et non réutilisable, pour chaque intention de paiement. Il le transmet dans un en-tête HTTP dédié, par exemple Idempotency-Key. Cette clé doit être associée à la demande exacte et rester identique pour toutes les tentatives de la même opération. Stockage serveur avec contrainte d’unicité Le serveur conserve une correspondance entre la clé d’idempotence et le résultat de l’opération. Une base de données relationnelle avec un index unique sur la clé, ou un cache distribué comme Redis avec une expiration contrôlée, convient parfaitement. La contrainte d’unicité empêche les conditions de course et garantit qu’une même clé ne peut produire deux résultats distincts. Flux de traitement côté serveur À chaque requête POST, le serveur interroge d’abord le stockage. Si la clé existe, il retourne immédiatement la réponse ou le statut précédemment enregistré, sans réexécuter la logique de paiement. Si la clé est absente, il traite la demande, enregistre le résultat sous cette clé, puis renvoie la réponse. Ce modèle garantit que le débit n’est exécuté qu’une seule fois, quel que soit le nombre de tentatives. Automate d’états rigoureux Le système de paiement doit respecter un cycle d’états strict, par exemple En attente, En cours, Terminé, Échoué. Une requête ne doit être traitée que si le paiement est dans un état intermédiaire. Les états Terminé ou Échoué doivent bloquer toute nouvelle exécution, même si une clé d’idempotence est présentée. Intégration native avec les passerelles de paiement La plupart des fournisseurs modernes acceptent nativement les clés d’idempotence. Il est préférable de les transmettre directement à la passerelle, qui se charge de la déduplication côté infrastructure. Cela réduit la surface d’erreur et aligne le comportement client et serveur. Politiques de retry côté client Le client doit limiter le nombre de tentatives, appliquer une backoff exponentielle avec un jitter, et s’assurer que la clé d’idempotence n’est pas régénérée à chaque essai. Un timeout bien calibré et un circuit breaker évitent les boucles de retry inutiles. Journalisation et réconciliation Conserver un audit immuable des requêtes, des clés utilisées, des résultats retournés et des horodatages permet de tracer chaque tentative, de détecter les anomalies et de réconcilier les comptes en cas de litige. En résumé, la sécurité d’un retry repose sur l’idempotence explicite, le stockage avec contrainte d’unicité, la gestion stricte des états transactionnels et la collaboration avec les passerelles de paiement. Cette architecture garantit qu’un timeout réseau ne peut jamais entraîner un double débit, tout en conservant une traçabilité complète et une expérience client fiable.

Ce code produit le résultat [2, 2, 2]. En effet, les fonctions lambda créées dans la boucle capturent la variable i par référence et non par valeur. Une fois la boucle terminée, la variable i conserve sa dernière valeur, soit 2. Par conséquent, chaque appel à f() retourne 2. Pour obtenir [0, 1, 2], vous devez figer la valeur de i au moment de la création de chaque lambda. La solution la plus idiomatique consiste à utiliser un argument par défaut dans la signature du lambda, comme suit : fs = [] for i in range(3): fs.append(lambda i=i: i) print([f() for f in fs]) Grâce à i=i, la valeur courante de i est copiée dans le paramètre local du lambda à chaque itération, ce qui garantit que chaque fonction retourne bien 0, 1 puis 2.

Voici l'ordre exact d'affichage : 1 4 3 2 Cette séquence respecte strictement le modèle d'exécution de JavaScript : le code synchrone s'exécute en premier (1, puis 4), la boucle d'événements traite ensuite les microtâches (Promise.then) avant les macrotâches (setTimeout), ce qui produit 3, puis 2. N'hésitez pas à me solliciter si vous souhaitez une analyse plus approfondie du mécanisme sous-jacent.

La première ligne de code applicatif à inspecter est la ligne 42 du fichier ui.js, au sein de la fonction renderUser. Vous devez identifier quelle variable, sur cette ligne, fait l'objet d'un accès à une propriété alors qu'elle vaut undefined. Il convient de vérifier la provenance de cette donnée, de confirmer que les arguments sont correctement passés par la fonction updatePage (app.js:18), et de vous assurer que la structure des objets correspond bien au modèle attendu. Si les données proviennent d'une API ou d'un état global, vérifiez leur initialisation et la validité des chemins d'accès.

Voici la fonction demandée, suivie de trois tests essentiels pour valider son comportement. Je reste à votre entière disposition pour toute intégration ou ajustement. function divide(a, b) { if (!Number.isFinite(a) !Number.isFinite(b)) { throw new Error("Les deux arguments doivent être des nombres finis."); } if (b === 0) { throw new Error("La division par zéro est interdite."); } return a / b; } // Test 1 : Division classique console.log(divide(10, 2)); // Retourne 5 // Test 2 : Division par zéro try { divide(10, 0); } catch (erreur) { console.log(erreur.message); // Affiche l'erreur explicite } // Test 3 : Entrée non finie try { divide(Infinity, 4); } catch (erreur) { console.log(erreur.message); // Affiche l'erreur explicite } Cette implémentation garantit une validation stricte des types et des valeurs, tout en fournissant des messages d'erreur clairs et exploitables. N'hésitez pas à me solliciter si vous souhaitez adapter ces tests à un framework spécifique ou les intégrer dans un pipeline de validation plus large.

Voici la fonction demandée, rédigée avec rigueur et en respectant strictement vos consignes. Elle utilise pathlib pour la gestion des chemins, vérifie l'absence de caractère absolu dans le second argument, et s'assure que le résultat final demeure bien à l'intérieur du répertoire racine. from pathlib import Path def safe_join(root, relative): root_path = Path(root).resolve() rel_path = Path(relative) if rel_path.is_absolute(): raise ValueError("Le chemin fourni en second argument ne doit pas être absolu.") joined = root_path / rel_path resolved = joined.resolve() if not resolved.is_relative_to(root_path): raise ValueError("Le chemin résolu sort du répertoire racine autorisé.") return resolved Explications techniques : Path(root).resolve() normalise la racine en un chemin absolu, sans liens symboliques ni segments redondants. rel_path.is_absolute() intercepte immédiatement toute tentative de chemin absolu, conformément à votre demande. root_path / rel_path concatène les chemins, puis .resolve() les normalise définitivement en suivant les liens symboliques. is_relative_to() garantit que le résultat final appartient bien à l'arborescence de root, même après résolution. La fonction retourne un objet Path résolu, ce qui correspond à l'usage standard de la bibliothèque. N'hésitez pas si vous souhaitez des précisions ou des adaptations. Je reste à votre entière disposition.