CodeQL bloqué par Xcode 27 : guide de dépannage 2026

L’analyse CodeQL échoue ou ne produit plus les résultats attendus après un changement de Xcode ou de macOS.

Déblocage immédiat : pour Swift, suspendez Swift 6.4 et fixez l’analyse sur macOS 26 ou une version antérieure avec Xcode 26 ou une version antérieure ; pour C/C++, C# et Java, évaluez le mode none seulement après avoir vérifié sa couverture.

Cet article s’adresse aux responsables IT et plateforme qui maintiennent les workflows GitHub Actions et CodeQL, aux équipes de sécurité qui livrent des projets Swift, ainsi qu’aux responsables des runners Mac. Il vous aide à isoler la limite rencontrée sans confondre compilation réussie, analyse complète et publication effective des résultats.

Dernière vérification le 24 octobre 2026, à partir de l’annonce de compatibilité publiée par GitHub le 19 octobre et de sa documentation CodeQL sur les langages compilés.

Analyse Swift avec Swift 6.4

Si votre dépôt utilise Swift 6.4, ne déduisez pas de la réussite de xcodebuild que CodeQL a analysé le code. L’annonce officielle précise que CodeQL ne prend pas en charge l’analyse de Swift 6.4 ; pour les analyses Swift et les tâches reposant sur le suivi de compilation, la voie recommandée est d’utiliser macOS 26 ou une version antérieure avec Xcode 26 ou une version antérieure (annonce de compatibilité de CodeQL pour macOS 27, Xcode 27 et Swift 6.4).

Il s’agit d’une limite de compatibilité de l’outil d’analyse, pas d’un diagnostic du compilateur. Votre application peut se construire correctement avec la nouvelle version du langage tandis que l’analyse de sécurité ne prend pas en charge ce langage. À l’inverse, une analyse qui s’exécute sans erreur visible ne démontre pas à elle seule que le code Swift a été extrait et couvert.

Pour décider, séparez les deux objectifs dans votre pipeline :

• si l’équipe doit adopter Swift 6.4 immédiatement, ne présentez pas le résultat CodeQL comme une validation de sécurité complète tant que l’analyse n’est pas prise en charge ;
• si le contrôle CodeQL est une condition obligatoire de fusion ou de publication, retardez l’adoption de Swift 6.4 pour ce dépôt ou conservez un environnement pris en charge pour l’analyse ;
• si compilation et analyse utilisent des runners distincts, documentez clairement la version de chaque environnement afin qu’un succès de compilation ne masque pas une analyse incomplète.

Cette séparation est particulièrement importante lorsque la validation de sécurité alimente un audit interne ou une décision de livraison. Le statut vert du travail de compilation indique que cette étape a abouti ; il ne certifie ni le contenu de la base CodeQL ni la présence des alertes attendues.

Extraction par suivi de compilation sous Xcode 27

L’installation de Xcode 27 rend indisponible l’extraction par suivi de compilation pour C/C++, C#, Go, Java, Kotlin et Swift, selon l’annonce officielle. La limite concerne donc plusieurs charges de travail, et pas uniquement les dépôts iOS. Elle ne signifie toutefois pas que toutes les analyses de ces langages échouent dans tous les modes : le mode CodeQL configuré reste déterminant.

Les langues et restrictions de ce comparatif sont celles de l’annonce officielle sur Xcode 27 et Swift 6.4 ; les possibilités et limites des modes figurent dans la documentation GitHub sur CodeQL pour les langages compilés.

Avant de changer la configuration, identifiez le mode réellement utilisé par chaque dépôt. Un workflow peut sélectionner une version de runner et de Xcode dans une définition, puis recevoir une image mise à jour ou une sélection différente dans un autre point de sa configuration. Consultez les journaux de la tâche et les paramètres de l’action CodeQL au lieu de vous fier au seul nom du workflow.

Runner macOS 27 et sélection de Xcode

macOS 27 et Xcode 27 correspondent à deux frontières de compatibilité liées, mais distinctes. L’annonce indique que l’extraction concernée peut ne pas fonctionner sur macOS 27 ; cette formulation ne permet pas de conclure que chaque analyse échoue nécessairement sur ce système. Pour isoler le problème, vérifiez le système de l’image réellement utilisée, la version de Xcode sélectionnée et le mode de construction de CodeQL.

La disponibilité d’une image runner avec Xcode 27 n’est pas une preuve de compatibilité du mode d’analyse. Les notes de publication de l’image indiquent sa disponibilité, tandis que l’annonce CodeQL précise les limites de l’extraction ; il faut donc traiter séparément ces informations (notes de publication de l’image runner Xcode 27).

Pour stabiliser votre pipeline, consignez ces éléments dans les paramètres du workflow ou dans un fichier de configuration contrôlé :

• l’image de runner demandée et le système effectivement rapporté pendant l’exécution ;
• la version de Xcode choisie par le runner, et non seulement celle attendue par l’équipe ;
• le mode de construction CodeQL et les langages analysés ;
• l’identifiant ou le chemin de la base d’analyse générée, ainsi que les journaux qui confirment l’extraction ;
• le résultat de l’analyse et l’état de téléversement des alertes.

Si le runner fournit macOS 27 ou Xcode 27, puis choisissez une image et une sélection de Xcode prises en charge pour l’analyse qui en dépend. Faites ensuite tourner à nouveau l’analyse dans cet environnement contrôlé. Cette comparaison permet de distinguer une incompatibilité de l’extracteur d’une erreur propre au dépôt, sans attribuer à macOS 27 une défaillance universelle que l’annonce ne confirme pas.

Mode none et couverture attendue

Le mode none peut être envisagé pour C/C++, C# et Java lorsque le suivi de compilation n’est pas disponible, mais il ne constitue pas un remplacement général et automatique. Les recommandations officielles précisent les langages pour lesquels il peut être considéré ; les options de construction et leurs limites sont détaillées dans la documentation sur les modes de build des langages compilés.

Avant de le conserver, évaluez le résultat par rapport à une base de référence connue ou à un environnement où le suivi est encore possible. Vérifiez notamment si la base contient les sources attendues, si les dépendances et les fichiers générés nécessaires sont représentés et si l’analyse retrouve les alertes pertinentes pour le dépôt. Le comportement sur du code généré mérite un contrôle spécifique ; la documentation dédiée aux alertes dans le code généré aide à interpréter cette partie de la couverture.

La décision doit être prise dépôt par dépôt. Un service Java dont l’analyse sans suivi couvre bien les sources utiles peut répondre aux exigences de l’équipe, tandis qu’un projet C/C++ dépendant de génération de code ou d’une configuration de compilation particulière peut nécessiter une vérification plus approfondie. Inscrivez les limites acceptées dans la décision de sécurité : ne remplacez pas un mode par un autre uniquement parce que le pipeline termine sans erreur.

Questions fréquentes sur les blocages CodeQL

Quels langages sont concernés par Xcode 27 ?
Pour l’extraction par suivi de compilation, l’annonce cite C/C++, C#, Go, Java, Kotlin et Swift. Cette liste décrit le périmètre affecté pour ce mode ; elle ne signifie pas que chaque mode d’analyse est inutilisable pour chacun de ces langages.

Pourquoi Swift 6.4 ne suffit-il pas à établir une analyse valide ?
La prise en charge de la compilation et celle de l’analyse CodeQL sont deux contrôles différents. Tant que Swift 6.4 n’est pas pris en charge par CodeQL, la réussite de la compilation ne prouve pas que l’extraction et l’analyse de sécurité couvrent le code.

Comment fixer macOS et Xcode ?
Faites correspondre la configuration demandée à l’image réellement attribuée au runner, puis vérifiez Xcode pendant l’exécution. Pour Swift et les tâches dépendant du suivi, utilisez macOS 26 ou une version antérieure avec Xcode 26 ou une version antérieure, conformément à l’avis publié.

build mode none remplace-t-il le suivi de compilation ?
Non, pas par défaut. Pour C/C++, C# et Java, vous pouvez l’évaluer si le suivi n’est pas disponible, mais comparez la base, les dépendances, le code généré et les résultats aux exigences du dépôt avant d’en faire le mode retenu.

Nœuds Intel et calendrier de migration

La dépréciation annoncée de la prise en charge des Mac Intel par CodeQL est un sujet distinct du blocage lié à Xcode 27 : le calendrier publié vise la mi-décembre 2026. Ne traitez donc pas le maintien temporaire d’un runner Intel comme un correctif à Swift 6.4 ou à l’extraction avec Xcode 27 ; répertoriez-le séparément dans votre plan de capacité et de migration (calendrier confirmé dans l’annonce de compatibilité).

Pour vos équipes, l’inventaire doit relier chaque nœud Intel aux dépôts et tâches CodeQL qui l’utilisent. Notez le propriétaire de la migration, le mode de construction et l’environnement cible prévu. Si l’analyse peut être exécutée sur un autre environnement pris en charge, vérifiez cette solution avant le retrait de la capacité Intel ; si elle dépend d’un Mac, consignez ce besoin sans le confondre avec une garantie que tout runner Mac conviendra.

Contrôle des résultats et du téléversement

Une exécution exploitable doit laisser des preuves au-delà du statut final du workflow. Une tâche peut démarrer et terminer, mais votre contrôle de sécurité doit encore établir que CodeQL a produit la base attendue, que l’analyse a abouti et que les résultats ont été transmis au service de code scanning. Le guide de téléversement des fichiers SARIF détaille les exigences de publication.

Utilisez cette liste de vérification lors de chaque reprise :

• [ ] Le workflow a journalisé l’image macOS réellement attribuée au runner.
• [ ] La version de Xcode utilisée est vérifiée dans l’exécution, et non supposée à partir de la configuration.
• [ ] Le mode de construction et les langages analysés correspondent à la décision documentée pour le dépôt.
• [ ] La base CodeQL a été générée et contient les sources attendues pour l’analyse.
• [ ] L’analyse a produit des résultats ; le statut vert de la compilation n’est pas utilisé comme preuve de couverture.
• [ ] Le fichier SARIF ou le mécanisme de publication configuré a été accepté, et les alertes sont visibles dans la destination prévue.

En cas d’échec, reprenez les contrôles dans cet ordre : environnement réel, mode d’extraction, génération de base, analyse, téléversement. Cette séquence évite de modifier simultanément l’image runner et la configuration CodeQL, ce qui rendrait difficile l’identification de la cause. Conservez les journaux et les paramètres de l’exécution de référence afin que l’équipe de sécurité puisse comparer les résultats après chaque changement.

Décision d’hébergement Mac

Avant d’ajouter ou de remplacer un nœud, vérifiez d’abord si le workflow exige réellement macOS et si son mode d’analyse est compatible avec l’environnement visé. Si l’analyse peut être exécutée sur une infrastructure déjà prise en charge, déplacer le job vers un Mac ne corrigera pas à lui seul une incompatibilité CodeQL avec Swift 6.4 ou un mode d’extraction rendu indisponible par Xcode 27.

Si le besoin Mac est confirmé, comparez un Mac détenu par l’entreprise et un Mac distant selon des critères vérifiables : contrôle de l’image et de Xcode, isolation des dépôts, gestion des secrets, accès aux journaux, continuité d’exploitation et responsabilités de maintenance. Un nœud propre à l’entreprise peut convenir lorsque la charge est stable et que l’équipe doit contrôler les interfaces physiques ou l’environnement local ; une capacité distante à durée flexible peut mériter une évaluation lorsque vous devez tester un environnement sans engager immédiatement un achat matériel. Ne concluez pas à un avantage de coût ou de performance sans données propres à votre charge de travail.

Pour situer les besoins de CI Mac avant cette comparaison, vous pouvez consulter les cas d’usage Mac proposés par KVMFLUX. Si vous étudiez ensuite une location, examinez les informations tarifaires KVMFLUX et vérifiez qu’elles répondent à vos contraintes de durée, d’accès et de sécurité ; elles ne remplacent pas la validation de la combinaison CodeQL, macOS et Xcode.

Commencez par inventorier les langages, le mode CodeQL et l’environnement réellement exécuté dans chaque dépôt, puis fixez une configuration prise en charge et contrôlez la base, l’analyse et le téléversement. Lorsque votre besoin de scan exige effectivement un Mac et que l’infrastructure actuelle ne peut pas le fournir, comparez un achat — avec son engagement matériel et sa maintenance — à une solution distante, dont il faut vérifier les modalités et l’adéquation au workflow avant de la retenir.

FAQ