{"meta":{"title":"Options et étapes de génération CodeQL pour les langages compilés","intro":"Découvrez comment CodeQL génère des langages compilés, y compris les modes de génération disponibles et le comportement de dépendance automatique spécifique au langage pour C/C++, C#, Go, Java, Kotlin, Rust et Swift.","product":"Sécurité et qualité du code","breadcrumbs":[{"href":"/fr/code-security","title":"Sécurité et qualité du code"},{"href":"/fr/code-security/reference","title":"Reference"},{"href":"/fr/code-security/reference/code-scanning","title":"Analyse du code"},{"href":"/fr/code-security/reference/code-scanning/codeql","title":"CodeQL"},{"href":"/fr/code-security/reference/code-scanning/codeql/build-options-for-compiled-languages","title":"Options de compilation pour les langages compilés"}],"documentType":"article"},"body":"# Options et étapes de génération CodeQL pour les langages compilés\n\nDécouvrez comment CodeQL génère des langages compilés, y compris les modes de génération disponibles et le comportement de dépendance automatique spécifique au langage pour C/C++, C#, Go, Java, Kotlin, Rust et Swift.\n\n## Étapes Autobuild pour les langages compilés\n\n```\n          Les runners hébergés par GitHub-sont toujours exécutés avec les logiciels requis par `autobuild`. Si vous utilisez des exécuteurs auto-hébergés pour GitHub Actions, vous devrez peut-être installer des logiciels supplémentaires pour utiliser le `autobuild` processus. En outre, si votre dépôt nécessite une version spécifique d’un outil de génération, vous devrez peut-être l’installer manuellement.               \n```\n\n> \\[!NOTE]\n> Si votre workflow utilise une matrice `language`, `autobuild` tente de générer chacun des langages compilés listés dans la matrice. Sans matrice, `autobuild` tente de générer le langage compilé pris en charge qui a le plus grand nombre de fichiers sources dans le dépôt. À l’exception de Go, l’analyse d’autres langages compilés dans votre dépôt échoue, sauf si vous fournissez des commandes de build explicites.\n\n## Compiler C/C++\n\nCodeQL prend en charge les modes `none`de génération ou `autobuild``manual` pour le code C/C++.\n\nLorsque vous activez la configuration par défaut pour un dépôt contenant du code C/C++, le mode de build est automatiquement défini sur `none`.\n\n### Aucune build pour C/C++\n\nCodeQL déduit les unités de compilation C/C++ via les extensions de fichier source. Pour chaque fichier source trouvé, les indicateurs de compilation et les chemins d’accès include sont déduits en inspectant le codebase sans avoir besoin d’une commande de build de travail.\n\n#### Précision de l'absence d'analyse de compilation pour C/C++\n\nLa création d’une CodeQL base de données C/C++ sans build peut produire des résultats moins précis que l’utilisation `autobuild` ou manuelle des étapes de génération dans certains cas ; par exemple, si :\n\n* Le code dépend fortement des macros personnalisées ou des définitions non disponibles dans les en-têtes existants.\n* Le codebase a de nombreuses dépendances externes\n\nVous pouvez garantir une analyse plus précise en suivant les étapes suivantes :\n\n* Placer des macros et définitions personnalisées dans des fichiers d'en-tête qui sont inclus dans des fichiers sources pertinents\n* Assurez-vous que les dépendances externes (headers) sont disponibles dans les répertoires d’inclusion système ou dans l’espace de travail.\n* Exécutez l’extraction sur la plateforme cible. Par exemple, choisissez un exécuteur Windows pour analyser des projets Windows afin de donner accès aux en-têtes et aux compilateurs spécifiques à la plateforme.\n\n### Résumé d’Autobuild pour C/C++\n\n| Type de système pris en charge | Nom du système                                                                                                                                      |\n| ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Système d'exploitation         | Windows, macOS et Linux                                                                                                                             |\n| Système de build               | Windows : scripts MSbuild et de construction<br/>Linux et macOS : Autoconf, Make, CMake, qmake, Meson, Waf, SCons, Linux Kbuild et scripts de build |\n\nLe comportement de l’étape `autobuild` varie en fonction du système d’exploitation sur lequel l’extraction s’exécute.\n\n### Détection automatique de Windows\n\nSur Windows, l’étape `autobuild` tente de détecter automatiquement une méthode de génération appropriée pour C/C++ à l’aide de l’approche suivante :\n\n1. Appeler `MSBuild.exe` sur le fichier solution (`.sln`) ou projet (`.vcxproj`) le plus proche de la racine.\n   Si `autobuild` détecte plusieurs fichiers solution ou projet à la même profondeur (la plus courte) à partir du répertoire de niveau supérieur, il tente de les générer tous.\n2. Appeler un script qui ressemble à un script de build : *build.bat*, *build.cmd* et *build.exe* (dans cet ordre).\n\n### Détection automatique Linux et macOS\n\nSur Linux et macOS, l’étape `autobuild` passe en revue les fichiers présents dans le dépôt pour déterminer le système de build utilisé :\n\n1. Rechercher un système de build dans le répertoire racine.\n2. Si aucun répertoire n’est trouvé, rechercher un répertoire unique avec un système de build pour C/C++.\n3. Exécuter une commande appropriée pour configurer le système.\n\n#### Exigences relatives au runner pour C/C++\n\nSur les runners Ubuntu Linux, `autobuild` peut tenter d’installer automatiquement les dépendances requises par la configuration et les étapes de build détectées. Par défaut, ce comportement est activé sur les exécuteurs hébergés GitHub et désactivé sur les exécuteurs auto-hébergés. Vous pouvez activer ou désactiver explicitement cette fonctionnalité en définissant `CODEQL_EXTRACTOR_CPP_AUTOINSTALL_DEPENDENCIES` sur `true` ou `false` dans l’environnement. Pour plus d’informations sur la définition de variables d’environnement, consultez [Stocker des informations dans des variables](/fr/actions/learn-github-actions/variables#defining-environment-variables-for-a-single-workflow).\n\nPour les runners auto-hébergés, sauf si l’installation automatique des dépendances est activée, vous devrez probablement installer le compilateur `gcc`, et certains projets peuvent également nécessiter l’accès aux exécutables `clang` ou `msvc`. Vous devrez également installer le système de build (par exemple `msbuild`, `make`, `cmake`, `bazel`) ainsi que les utilitaires (tels que `python`, `perl`, `lex` et `yacc`) dont vos projets dépendent.\nSi vous activez l’installation automatique des dépendances, vous devez vous assurer que le runner utilise Ubuntu et qu’il peut exécuter `sudo apt-get` sans nécessiter de mot de passe.\n\nLes runners Windows exigent que `powershell.exe` soit présent dans le `PATH`.\n\n## Compiler C\\#\n\nCodeQL prend en charge les modes `none`, `autobuild` ou `manual` pour le code C#.\n\nLorsque vous activez la configuration par défaut pour un dépôt contenant du code C#, le mode de build est automatiquement défini sur `none`.\n\n### Analyse sans build pour C\\#\n\nCodeQL restaure les dépendances et génère quelques fichiers sources supplémentaires, pour donner des résultats plus précis, avant de créer une base de données à partir de tous les fichiers sources et dépendances.\n\nLes dépendances sont restaurées à l’aide de plusieurs heuristiques et stratégies. Les fichiers suivants constituent les principales sources d’information : `*.csproj`, `*.sln`, `nuget.config`, `packages.config`, `global.json` et `project.assets.json`.\nSi un flux de paquets NuGet privé est défini pour l'organisation, il est également utilisé ; consultez [l'accès par défaut de l'analyse du code aux registres privés](/fr/code-security/securing-your-organization/enabling-security-features-in-your-organization/giving-org-access-private-registries#code-scanning-default-setup-access-to-private-registries) et [détermination si l'analyse du code par défaut utilise des registres privés](/fr/code-security/code-scanning/managing-your-code-scanning-configuration/viewing-code-scanning-logs#determining-whether-code-scanning-default-setup-used-any-private-registries).\n\nLes fichiers sources générés suivants sont facultatifs, mais augmentent considérablement la justesse de la CodeQL base de données :\n\n* ```\n            directives `global``using` générées pour gérer la fonctionnalité implicite `using` de MSbuild.\n  ```\n* fichiers d'affichage d'ASP.NET Core, les fichiers `.cshtml` sont convertis en fichiers `.cs`.\n\nLes informations issues des noms des assemblies de dépendances, des fichiers sources générés, des dépendances stockées dans des flux privés, ainsi que des fichiers sources du référentiel sont compilées et utilisées pour créer une base de données.\n\n#### Précision de l’analyse sans build pour C\\#\n\nLa création d’une CodeQL base de données sans générer le code complet repose sur la possibilité de restaurer des dépendances et de pouvoir compiler ensemble les fichiers sources dans le référentiel. En cas de problème lors de la restauration des dépendances ou de la compilation du code source, cela peut affecter la précision de la CodeQL base de données et code scanning des résultats d’analyse.\n\nVous pouvez garantir une analyse plus précise en suivant les étapes suivantes :\n\n* Fournissez l’accès à l’Internet public ou assurez-vous que l’accès à un flux NuGet privé est disponible, voir [la configuration par défaut de l’accès au Code scanning aux registres privés](/fr/code-security/securing-your-organization/enabling-security-features-in-your-organization/giving-org-access-private-registries#code-scanning-default-setup-access-to-private-registries).\n* Vérifiez si le dépôt requiert plusieurs versions d’une même dépendance NuGet.\n  CodeQL ne peut utiliser qu’une seule version et choisit généralement la version la plus récente où il existe plusieurs versions. Cette approche peut ne pas convenir à tous les dépôts.\n* Vérifiez si plusieurs versions de .NET sont référencées, par exemple, `net48`, `net5.0` et `netstandard1.6`.\n  CodeQL ne peut utiliser qu’une seule version et cela peut affecter la précision.\n* Évitez les collisions de noms de classes, sinon cela peut entraîner l’absence de cibles d’appel de méthode, ce qui a un impact sur l’analyse de flux de données.\n\n### Résumé de la compilation automatisée pour C\\#\n\n| Type de système pris en charge | Nom du système                                  |\n| ------------------------------ | ----------------------------------------------- |\n| Système d'exploitation         | Windows, macOS et Linux                         |\n| Système de build               | .NET et MSBuild, ainsi que des scripts de build |\n\n#### Détection automatique de Windows\n\nLe processus `autobuild` tente de détecter automatiquement une méthode de génération appropriée pour C# en utilisant l’approche suivante :\n\n1. Appeler `dotnet build` sur le fichier solution (`.sln`) ou projet (`.csproj`) le plus proche de la racine.\n2. Appeler `MSBuild.exe` sur le fichier de solution ou de projet le plus proche de la racine.\n   Si `autobuild` détecte plusieurs fichiers solution ou projet à la même profondeur (la plus courte) à partir du répertoire de niveau supérieur, il tente de les générer tous.\n3. Appeler un script ressemblant à un script de build —`build.bat`, `build.cmd` et `build.exe` (dans cet ordre).\n\n#### Conditions requises pour l'exécution de C# sous Windows\n\nPour le développement d’applications .NET Core sur les exécuteurs auto-hébergés, le kit sdk .NET est requis (pour `dotnet`).\n\nPour le développement d’applications .NET Framework, vous aurez besoin de Microsoft Build Tools (pour `msbuild`) et de l’interface CLI NuGet (pour `nuget`).\n\nLes runners Windows exigent que `powershell.exe` soit présent dans le `PATH`.\n\nSi vous envisagez de créer CodeQL des bases de données en utilisant `build-mode: none`, vous devez également fournir l'accès à Internet ou vous assurer que l'accès à un flux NuGet privé est disponible.\n\n#### Détection automatique Linux et macOS\n\n1. Appeler `dotnet build` sur le fichier solution (`.sln`) ou projet (`.csproj`) le plus proche de la racine.\n2. Appeler `MSbuild` sur le fichier de solution ou de projet le plus proche de la racine.\n   Si `autobuild` détecte plusieurs fichiers solution ou projet à la même profondeur (la plus courte) à partir du répertoire de niveau supérieur, il tente de les générer tous.\n3. Appeler un script ressemblant à un script de build —`build` et `build.sh` (dans cet ordre).\n\n#### Exigences relatives au runner pour C# sous Linux et macOS\n\nPour le développement d’applications .NET Core sur les exécuteurs auto-hébergés, le kit sdk .NET est requis (pour `dotnet`).\n\nPour le développement d’applications .NET Framework, vous avez besoin de Mono Runtime (pour exécuter `mono`, `msbuild` ou `nuget`).\n\nSi vous envisagez de créer CodeQL des bases de données en utilisant `build-mode: none`, vous devez également fournir l'accès à Internet ou vous assurer que l'accès à un flux NuGet privé est disponible.\n\n### Indicateurs du compilateur C# injectés par CodeQL pour des builds manuelles\n\nLe CodeQL traceur permet l’extraction de tous les langages compilés en interceptant les processus de génération et en transférant des informations aux extracteurs de langage appropriés CodeQL . Le traceur injecte certains indicateurs dans l’appel du compilateur C# pour vous assurer que chaque composant est généré et inclus dans la CodeQL base de données, ce qui peut entraîner la génération de votre code C# d’une manière différente de ce que vous attendez pendant CodeQL l’analyse.\n\n#### `/p:MvcBuildViews=true`\n\nLorsque cette option est définie sur `true`, les vues dans ASP.NET projets MVC (model-view-controller) sont précompilées dans le cadre du processus de génération, ce qui peut aider à intercepter les erreurs et à améliorer les performances. Le traceur injecte cet indicateur pour s'assurer que CodeQL trouve et mette en évidence les problèmes de sécurité qui peuvent impliquer le flux de données à travers le code généré à partir de ces vues. Pour plus d’informations, consultez [Ajouter un affichage à une application MVC](https://learn.microsoft.com/en-us/aspnet/mvc/overview/getting-started/introduction/adding-a-view) dans Microsoft Learn.\n\n#### `/p:UseSharedCompilation=false`\n\nDéfinir cette option sur `false` désactive l’utilisation de la fonctionnalité de compilation partagée, ce qui peut entraîner des temps de build plus longs. Lorsque `/p:UseSharedCompilation=false` n’est **pas** spécifié, `msbuild` démarre un processus serveur de compilateur et toutes les compilations seront effectuées par ce seul processus. Toutefois, le CodeQL traceur dépend de l’inspection des arguments des processus nouvellement créés.\n\n#### `/p:EmitCompilerGeneratedFiles=true`\n\nDéfinir cette option sur `true` émet des fichiers générés par le compilateur pendant le processus de build. Cette option entraîne la génération par le compilateur de fichiers source supplémentaires utilisés pour prendre en charge des fonctionnalités telles que l’amélioration de la prise en charge des expressions régulières, la sérialisation et la génération de vues d’applications web. Ces artefacts générés ne sont généralement pas écrits sur le disque par le compilateur, mais le fait de définir l’option sur `true` force l’écriture des fichiers sur le disque afin que l’extracteur puisse les traiter.\n\nPour certains projets hérités et les projets qui utilisent des fichiers `.sqlproj`, vous pouvez constater que la propriété `/p:EmitCompilerGeneratedFiles=true` injectée entraîne des problèmes inattendus avec `msbuild`. Pour plus d’informations sur le dépannage, consultez [Échec inattendu du compilateur C#](/fr/code-security/code-scanning/troubleshooting-code-scanning/c-sharp-compiler-unexpectedly-failing).\n\n## Compiler Go\n\nCodeQL prend en charge les modes de build `autobuild` ou `manual` pour le code Go.\n\n### Résumé d’Autobuild pour Go\n\n| Type de système pris en charge | Nom du système                                                                                            |\n| ------------------------------ | --------------------------------------------------------------------------------------------------------- |\n| Système d'exploitation         | Windows, macOS et Linux                                                                                   |\n| Système de build               | Modules Go, `dep` et Glide, ainsi que des scripts de génération, notamment des scripts Makefiles et Ninja |\n\n### Détection automatique pour Go\n\nLe processus `autobuild` tente de détecter automatiquement un moyen approprié d’installer les dépendances dont un dépôt Go a besoin avant d’extraire tous les fichiers `.go` :\n\n1. Appelez `make`, `ninja`, `./build` ou `./build.sh` (dans cet ordre) jusqu’à ce que l’une de ces commandes réussisse et qu’une commande `go list ./...` ultérieure réussisse également, indiquant que les dépendances nécessaires ont été installées.\n2. Si aucune de ces commandes ne réussit, recherchez `go.mod`, `Gopkg.toml` ou `glide.yaml`, et exécutez `go get` (sauf si le vendoring est utilisé), `dep ensure -v` ou `glide install` respectivement pour essayer d’installer les dépendances.\n3. Enfin, si les fichiers de configuration de ces gestionnaires de dépendances sont introuvables, réorganisez la structure de répertoires du dépôt pour l’ajouter à `GOPATH` et utilisez `go get` pour installer les dépendances. La structure de répertoires revient à la normale une fois l’extraction terminée.\n4. Extrayez tout le code Go dans le dépôt, comme pour l’exécution de `go build ./...`.\n\n> \\[!NOTE]\n> Si vous utilisez la configuration par défaut, il recherche un `go.mod` fichier pour installer automatiquement une version compatible de la langue Go.\n\n### Options de l’extracteur pour Go\n\nPar défaut, le code de test (code dans les fichiers se terminant par `_test.go`) n’est pas analysé. Vous pouvez passer outre avec l'option `--extractor-option extract_tests=true` lors de l'utilisation de CodeQL CLI, ou en définissant la variable d'environnement `CODEQL_EXTRACTOR_GO_OPTION_EXTRACT_TESTS` sur `true`.\n\nEn outre, les répertoires `vendor` sont exclus par défaut de l’analyse Go CodeQL. Vous pouvez annuler cela en passant l’option `--extractor-option extract_vendor_dirs=true` lors de l’utilisation de CodeQL CLI, ou en définissant la variable d’environnement `CODEQL_EXTRACTOR_GO_OPTION_EXTRACT_VENDOR_DIRS` sur `true`.\n\n## Développement en Java et Kotlin\n\nCodeQL prend en charge les modes de génération suivants.\n\n* Java : `none`, `autobuild` ou `manual`\n* Kotlin : `autobuild` ou `manual`\n\nLorsque vous activez d’abord la configuration par défaut d’un référentiel, si seul Java code est détecté, le mode de génération est défini sur `none`. Si Kotlin ou une combinaison de code Java et Kotlin est détectée, le mode de génération est défini sur `autobuild`.\n\nSi vous ajoutez ultérieurement du code Kotlin à un référentiel qui utilise le `none` mode de génération, CodeQL l’analyse signale un message d’avertissement expliquant que Kotlin n’est pas pris en charge. Vous devrez désactiver la configuration par défaut puis la réactiver. Lorsque vous réactivez la configuration par défaut, le mode de build passera à `autobuild` afin que les deux langages puissent être analysés. Vous pouvez aussi passer à une configuration avancée. Pour plus d’informations, consultez « [Avertissement : X fichiers Kotlin détectés dans votre projet qui n'ont pas pu être traités sans compilation](/fr/code-security/code-scanning/troubleshooting-code-scanning/kotlin-detected-in-no-build) ».\n\n### Aucune build pour Java\n\nCodeQL tentera d’exécuter Gradle ou Maven pour extraire des informations de dépendance précises (mais pas pour appeler une build), avant de créer une base de données à partir de tous les fichiers Java présents. Chaque fichier de projet Maven ou Gradle racine (un script de build sans script de build présent dans un répertoire ancêtre) est interrogé pour obtenir des informations de dépendances, et les versions de dépendances les plus récentes sont privilégiées en cas de conflit. Pour plus d’informations sur les exigences de l’exécuteur pour exécuter Maven ou Gradle, consultez [ Conditions requises pour Java](#runner-requirements-for-java).\n\nSi un registre Maven privé est défini pour l’organisation, il est également utilisé, consultez [l’accès au programme d’installation par défaut de l’analyse du code aux registres privés](/fr/code-security/securing-your-organization/enabling-security-features-in-your-organization/giving-org-access-private-registries#code-scanning-default-setup-access-to-private-registries) et [déterminer si l’installation par défaut de l’analyse du code a utilisé tous les registres privés](/fr/code-security/code-scanning/managing-your-code-scanning-configuration/viewing-code-scanning-logs#determining-whether-code-scanning-default-setup-used-any-private-registries).\n\n#### Précision de l'analyse sans compilation pour Java\n\nLa création d’une base de données CodeQL Java sans build peut produire des résultats moins précis que l’utilisation de `autobuild` ou des étapes de génération manuelles si :\n\n* Les scripts de build Gradle ou Maven ne peuvent pas être interrogés pour les informations de dépendance et les estimations de dépendance (basées sur des noms de package Java) sont inexactes.\n* Le dépôt génère normalement du code pendant le processus de build. Cette opération est analysée si vous avez créé la CodeQL base de données en utilisant un autre mode.\n\nVous pouvez garantir une analyse plus précise en suivant les étapes suivantes :\n\n* Fournissez l’accès à Internet public ou assurez l'accès à un référentiel d’artefacts privés, consultez la configuration par défaut de l'analyse de code pour l'accès aux[](/fr/code-security/securing-your-organization/enabling-security-features-in-your-organization/giving-org-access-private-registries#code-scanning-default-setup-access-to-private-registries) registres privés.\n* Vérifiez si le dépôt requiert plusieurs versions d’une même dépendance.\n  CodeQL ne peut utiliser qu’une seule version et choisit généralement la version la plus récente où il existe plusieurs versions. Cette approche peut ne pas convenir à tous les dépôts.\n* Vérifiez si plusieurs versions de l’API JDK sont requises par différents fichiers Java sources. Lorsque plusieurs versions sont visibles, CodeQL utilisez la version la plus élevée requise par n’importe quel script de build. Cela peut signifier que certains fichiers nécessitant une version inférieure du JDK seront partiellement analysés. Par exemple, si certains fichiers nécessitent JDK 8, mais qu’une exigence JDK 17 est trouvée dans un ou plusieurs scripts de build, CodeQL utilise JDK 17. Les fichiers nécessitant JDK 8 et qui ne peuvent pas être compilés avec JDK 17 seront partiellement analysés.\n* Évitez les collisions de noms de classes (par exemple plusieurs fichiers définissant `org.myproject.Test`), sinon cela peut entraîner l’absence de cibles d’appel de méthode, ce qui a un impact sur l’analyse de flux de données.\n\n### Résumé de la compilation automatisée pour Java\n\n| Type de système pris en charge | Nom du système                               |\n| ------------------------------ | -------------------------------------------- |\n| Système d'exploitation         | Windows, macOS et Linux (aucune restriction) |\n| Système de build               | Gradle, Maven et Ant                         |\n\n### Détection automatique pour Java\n\nLe processus `autobuild` tente de déterminer le système de génération pour les bases de code Java en appliquant cette stratégie :\n\n1. Rechercher un fichier de build dans le répertoire racine. Rechercher les fichiers de build Gradle, puis Maven, puis Ant.\n2. Exécuter le premier fichier de build trouvé. Si les fichiers Gradle et Maven sont présents, le fichier Gradle est utilisé.\n3. Sinon, rechercher les fichiers de build dans les sous-répertoires directs du répertoire racine. Si un seul sous-répertoire contient des fichiers de build, exécutez le premier fichier identifié dans ce sous-répertoire (en utilisant la même préférence que pour 1). Si plusieurs sous-répertoires contiennent des fichiers de build, signaler une erreur.\n\n### Conditions requises pour Runner de Java\n\nSi vous utilisez des exécuteurs auto-hébergés, la ou les versions requises de Java doivent être présentes :\n\n* Si l’exécuteur sera utilisé pour analyser les référentiels nécessitant une version unique de Java, la version JDK appropriée doit être installée et doit être présente dans la variable PATH (afin que `java` et `javac` soient trouvés).\n\n* Si l’exécuteur sera utilisé pour analyser les référentiels nécessitant plusieurs versions de Java, les versions JDK appropriées doivent être installées et peuvent être spécifiées via le fichier `toolchains.xml`. Il s’agit d’un fichier de configuration, généralement utilisé par Apache Maven, qui permet de spécifier l’emplacement des outils, leur version et toute configuration supplémentaire requise pour les utiliser. Pour plus d’informations, consultez le [Guide d’utilisation des chaînes d’outils](https://maven.apache.org/guides/mini/guide-using-toolchains.html) dans la documentation Apache Maven.\n\nLes exécutables suivants seront probablement requis pour une plage de projets Java et doivent être présents dans la variable PATH, mais ils ne seront pas essentiels dans tous les cas :\n\n* `mvn` (Apache Maven)\n* ```\n            `gradle` (Gradle)\n  ```\n* `ant` (Apache Ant)\n\nVous devrez également installer le système de build (par exemple `make`, `cmake`, `bazel`) ainsi que les utilitaires (tels que `python`, `perl`, `lex`, et `yacc`) dont vos projets dépendent.\n\nLes runners Windows exigent que `powershell.exe` soit présent dans le `PATH`.\n\n## Compilation de Rust\n\nCodeQL prend en charge le mode `none` de génération pour le code Rust.\n\n### Aucune build pour Rust\n\nCodeQL utilise `rust-analyzer` pour compiler et exécuter des scripts de build (`build.rs` fichiers) et compiler du code macro, mais n’appelle pas de build complète. Une base de données est créée à partir de tous les fichiers Rust présents. Un `Cargo.toml` ou `rust-project.json` fichier doit être présent.\n\n### Exigences du runner pour Rust\n\nL’analyse Rust nécessite que `rustup` et `cargo` soient installés.\n\n## Compiler Swift\n\nCodeQL prend en charge les modes de build `autobuild` ou `manual` pour le code Swift.\n\n### Résumé d’Autobuild pour Swift\n\n| Type de système pris en charge | Nom du système |\n| ------------------------------ | -------------- |\n| Système d'exploitation         | macOS          |\n| Système de build               | Xcode          |\n\nLe processus `autobuild` tente de générer la plus grande cible à partir d’un projet ou d’un espace de travail Xcode.\n\nL’analyse du code Swift utilise des exécuteurs macOS par défaut. Étant donné que les exécuteurs macOS hébergés sont plus coûteux que les exécuteurs Linux et Windows, nous vous recommandons de construire uniquement le code que vous souhaitez analyser. Pour plus d’informations sur les prix pour les exécuteurs hébergés par GitHub, consultez [Facturation des actions GitHub](/fr/billing/managing-billing-for-github-actions/about-billing-for-github-actions).\n\nCode scanning du code Swift n’est pas pris en charge pour les exécuteurs qui font partie d’un Actions Runner Controller (ARC), car les exécuteurs ARC utilisent uniquement Linux et Swift nécessitent des exécuteurs macOS. Toutefois, vous pouvez avoir un mélange d’exécuteurs ARC et d’exécuteurs macOS auto-hébergés. Pour plus d’informations, consultez « [Actions Runner Controller](/fr/actions/concepts/runners/actions-runner-controller) ».\n\n### Personnalisation de la compilation Swift dans un Workflow d’analyse CodeQL\n\n`xcodebuild` et `swift build` sont tous deux pris en charge pour les builds Swift. Nous vous recommandons de cibler une seule architecture pendant la génération. Par exemple, `ARCH=arm64` pour `xcodebuild`, ou `--arch arm64` pour `swift build`.\n\nVous pouvez passer les options `archive` et `test` à `xcodebuild`. Toutefois, il est recommandé d'utiliser la commande standard `xcodebuild`, car elle devrait être la plus rapide et suffisante pour qu'une analyse réussie soit effectuée avec CodeQL.\n\nPour l’analyse Swift, vous devez toujours installer explicitement les dépendances gérées via CocoaPods ou Carthage avant de générer la CodeQL base de données."}