Dernière mise à jour : 7 septembre 2026. Les informations Flutter ont été vérifiées dans les notes officielles de Flutter 3.44.0, puis confrontées aux documents Apple sur la signature et la distribution.

Flutter 3.44.0 est la version concernée : sa chaîne de publication iOS passe toujours par macOS, Xcode et la signature Apple, comme le rappelle la documentation officielle de déploiement iOS de Flutter. Si vous rencontrez un échec de signature Flutter 3.44, ne révoquez donc pas immédiatement vos certificats et ne supprimez pas tout le trousseau. Cette semaine, commencez par identifier l’étape fautive — projet, identité de signature, Target, entitlements ou trousseau distant — puis validez successivement une Release Archive, l’export IPA et un envoi réel.

Cette méthode évite de confondre un simple échec de flutter build ios avec un problème d’exportation ou d’App Store Connect. Une commande peut générer des fichiers tout en produisant un paquet impossible à distribuer.

Cet article s’adresse à vous si :

  • vous développez depuis Windows ou Linux et utilisez un Mac distant pour publier une application Flutter ;
  • un projet existant rencontre une erreur de signature après le passage à Flutter 3.44 ;
  • vous devez faire fonctionner flutter build ipa depuis SSH, un script ou une intégration continue sans intervention graphique.
01

Le premier diagnostic : localiser précisément l’étape qui échoue

Le cas le plus trompeur est celui-ci : le projet anonymisé <PROJET_FLUTTER> s’Archive correctement depuis Xcode avec la session graphique ouverte, mais la commande exécutée par SSH échoue pendant flutter build ipa. Le dernier message contient codesign, ce qui pousse souvent à réimporter un certificat. Ce raccourci est risqué.

La chaîne contient plusieurs opérations distinctes :

  1. compilation Flutter et génération du projet iOS ;
  2. compilation Xcode du Target Runner et des éventuels Targets d’extensions ;
  3. création de l’Archive Release ;
  4. exportation de l’IPA selon une méthode de distribution ;
  5. vérification de la signature et des entitlements ;
  6. envoi vers App Store Connect.

La documentation Apple sur l’Archive et la distribution distingue elle aussi l’Archive de l’étape de distribution. Le fichier .xcarchive n’est donc pas une preuve d’envoi réussi.

Commencez par conserver, sous forme désensibilisée, les éléments suivants :

  • la première erreur utile, et non la dernière ligne codesign ;
  • le Target en échec : <TARGET_RUNNER>, <TARGET_WIDGET> ou <TARGET_EXTENSION> ;
  • la configuration active : Debug, Release ou une configuration personnalisée ;
  • le Scheme réellement utilisé ;
  • le chemin du projet et du trousseau, remplacés par <CHEMIN_PROJET> et <TROUSSEAU> ;
  • le mode de lancement : Xcode, terminal graphique, SSH ou tâche automatisée.

Faites ensuite deux essais avec le même commit : une Archive Release dans Xcode, puis la commande Flutter depuis le terminal. Si les deux échouent au même Target et avec la même identité, commencez par le projet. Si seul SSH échoue, l’environnement distant devient le suspect principal.

02

La configuration de Runner doit rester cohérente jusqu’à l’export

Dans Xcode, ouvrez le projet iOS généré et contrôlez le Target Runner, le Scheme de publication et la configuration Release. Le champ Team doit correspondre à l’équipe qui possède l’App ID associé à <BUNDLE_ID>. Une équipe sélectionnée dans un Target ne suffit pas si l’export utilise un autre Scheme ou si une extension conserve une ancienne valeur.

Vérifiez les correspondances suivantes :

Élément contrôlé Valeur à comparer Échec typique
Team de Runner Équipe du compte Apple Developer Flutter demande de sélectionner une équipe
Bundle ID principal App ID enregistré Profil introuvable ou non applicable
Scheme de publication Configuration Release attendue La commande utilise une configuration différente
Target d’extension App ID propre à l’extension Archive partielle ou signature refusée
Méthode d’export Distribution prévue IPA créée mais non valide pour l’envoi

Le mode automatique peut créer ou sélectionner certains profils, tandis que le mode manuel dépend de profils explicitement choisis. Le danger n’est pas d’utiliser l’un ou l’autre ; c’est de les mélanger sans savoir à quel niveau la décision est prise. Contrôlez le projet, chaque Target et les options d’export au lieu de changer trois réglages simultanément.

Le premier critère de réussite n’est pas « le build Debug fonctionne ». Le même commit doit produire une Archive Release signée, avec le bon Bundle ID et le bon Team ID, par le chemin que vous comptez réellement automatiser.

Pour comprendre les exigences Apple avant de modifier votre projet, consultez aussi la page Apple consacrée à la préparation d’une application pour la distribution.

03

Le certificat ne suffit pas : il faut une identité complète

Un certificat .cer ou .p12 n’est pas, à lui seul, une identité de signature exploitable. Il faut vérifier quatre éléments :

  • le certificat de développement ou de distribution approprié ;
  • la clé privée correspondante ;
  • l’identité visible dans le trousseau utilisé par Xcode ou codesign ;
  • le Provisioning Profile compatible avec le Bundle ID, la distribution et les capacités.

Apple décrit les familles de certificats dans sa documentation officielle sur les certificats. La différence entre un certificat présent et une identité complète est essentielle sur un Mac distant : importer uniquement le certificat public peut laisser la clé privée absente, inaccessible ou installée dans un autre trousseau.

Pour le profil, comparez au minimum :

  • l’App ID et le Bundle ID ;
  • le type de distribution demandé ;
  • le certificat autorisé par le profil ;
  • les capacités activées ;
  • le Target auquel le profil est réellement appliqué.

La note technique Apple « Inside Code Signing: Provisioning Profiles » explique le rôle du profil dans cette relation entre application, certificat et autorisations.

Avant de révoquer un certificat, supprimer un profil ou recréer une clé privée, exportez les actifs nécessaires dans un emplacement protégé et notez les machines qui les utilisent. Une révocation peut interrompre une publication déjà préparée, un autre poste de compilation ou une tâche en cours. Si vous ne pouvez pas restaurer l’identité complète et son accès, revenez à l’état précédent plutôt que d’accumuler de nouveaux certificats.

04

Les Targets secondaires peuvent être la vraie cause

Un projet Flutter peut sembler correctement configuré tant que vous ne vérifiez que Runner. Pourtant, une notification push, un widget, une extension de partage ou un plugin peut ajouter un Target avec son propre Bundle ID, ses propres capacités et son propre profil.

Traitez chaque Target séparément :

  1. ouvrez Signing & Capabilities ;
  2. relevez le Team et le Bundle ID ;
  3. identifiez le profil de développement ou de distribution ;
  4. comparez les capacités avec l’App ID ;
  5. vérifiez les entitlements générés ;
  6. inspectez le produit placé dans l’Archive.

Le dernier point est déterminant. Le réglage visible dans le projet ne prouve pas que le produit final porte les mêmes déclarations. Les entitlements sont attachés au binaire signé et doivent être compatibles avec les autorisations du profil. La référence Apple sur les entitlements constitue la base à utiliser pour cette comparaison.

Par exemple, si <TARGET_WIDGET> déclare une capacité absente de son profil, Runner peut être correctement signé alors que l’export échoue. Dans ce cas, modifier uniquement le profil de Runner ne résoudra rien. Corrigez le Target fautif, régénérez ou sélectionnez le profil approprié, puis recréez l’Archive.

Évitez aussi de supposer que tous les Targets doivent avoir un Bundle ID identique. Ils doivent appartenir à une configuration d’équipe cohérente, mais une extension possède normalement un identifiant distinct.

05

Le Mac distant ajoute une couche de trousseau et de session

Lorsque Xcode fonctionne et que SSH échoue, comparez les contextes d’exécution avant de toucher aux certificats. Une session graphique peut avoir déjà déverrouillé le trousseau, accepté une autorisation ou chargé une variable d’environnement. Une tâche SSH non interactive ne bénéficie pas automatiquement de ces conditions.

Effectuez le diagnostic en cinq étapes :

  1. depuis un terminal graphique, lancez la commande de publication avec le commit <COMMIT_ID> ;
  2. depuis SSH, relancez exactement la même commande et le même Scheme ;
  3. identifiez le trousseau contenant l’identité de signature ;
  4. vérifiez quel trousseau est par défaut pour le compte de construction ;
  5. contrôlez si le processus non interactif peut utiliser la clé privée.

Ne placez pas un mot de passe, un jeton App Store Connect ou une clé privée en clair dans un script. Limitez l’accès au compte de construction et n’accordez à une tâche que les droits nécessaires. Toute modification de la liste de contrôle d’accès du trousseau doit être documentée avec son périmètre et sa méthode de retour arrière.

Les problèmes de session ne sont pas une règle universelle de Flutter 3.44. Ils doivent être confirmés sur votre environnement : même projet, même Mac, même compte, même version de Xcode et mêmes variables. Les forums Apple consacrés aux problèmes de signature constituent un point de comparaison officiel pour les cas SSH et codesign, mais un cas communautaire ne remplace pas votre propre trace d’exécution.

06

La validation doit suivre la chaîne complète de publication

Ne concluez pas que le problème est réglé parce que flutter build ipa termine sans erreur. Utilisez cette séquence de contrôle :

  1. exécutez flutter clean uniquement si vous avez identifié une raison précise ; ne supprimez pas les caches par réflexe ;
  2. lancez la génération iOS avec le Scheme et la configuration attendus ;
  3. exécutez flutter build ipa et conservez la première erreur utile ;
  4. vérifiez que l’Archive contient Runner et toutes les extensions attendues ;
  5. exportez l’IPA avec la méthode de distribution prévue ;
  6. contrôlez la signature et les entitlements du produit exporté ;
  7. effectuez une validation ou un envoi réel vers App Store Connect ;
  8. répétez après déconnexion, redémarrage ou nouvelle session si le Mac doit servir de serveur permanent.

Si l’Archive réussit mais que l’export échoue, concentrez-vous sur la méthode de distribution, le profil et les entitlements. Si l’IPA est créée mais refusée lors de la validation, inspectez le produit signé, pas seulement la sortie Flutter. Si le lancement après redémarrage échoue, l’environnement distant n’est pas encore reproductible.

07

La décision finale se prend avec des conditions vérifiables

Utilisez les branches suivantes plutôt que de reconstruire toute la chaîne à chaque erreur :

  • Si Xcode et SSH échouent sur le même Target, corrigez d’abord le projet, le Team, le Bundle ID ou le profil associé.
  • Si Xcode réussit, mais SSH échoue avec la même révision, corrigez le trousseau, la session et les droits non interactifs avant de recréer les certificats.
  • Si Runner réussit mais qu’une extension échoue, inspectez le Bundle ID, les capacités et le profil de ce Target secondaire.
  • Si l’Archive réussit mais que l’IPA échoue, passez à l’étape d’export et aux entitlements ; ne revenez pas automatiquement à la compilation Flutter.
  • Si l’IPA est exportée mais rejetée à la validation, comparez les entitlements réellement signés au profil utilisé pour chaque produit.
  • Si le succès disparaît après redémarrage, choisissez un environnement macOS dont le trousseau et les accès peuvent être restaurés de manière contrôlée.
  • Si le même commit passe l’Archive, l’export et l’envoi après une nouvelle connexion, vous pouvez considérer l’environnement comme candidat à une utilisation permanente.

Cette méthode répond aussi à la question de fond : faut-il réparer le projet, reconstruire l’environnement de signature ou changer de Mac de compilation ? La preuve doit venir de la chaîne Release complète, pas d’un simple message de compilation.

08

Questions fréquentes sur la signature Flutter 3.44

Ces réponses reprennent les quatre erreurs de recherche les plus fréquentes, avec une procédure distincte pour chacune.

Pourquoi flutter build ipa demande-t-il de choisir une équipe de développement ?

Cette demande indique généralement que la configuration active ne fournit pas une équipe valide pour le Target concerné, ou que l’exécution utilise un autre projet, une autre configuration ou un autre Bundle ID. Vérifiez le Scheme réellement lancé, le champ Team de Runner et les Targets d’extensions, puis comparez ces valeurs avec l’App ID enregistré dans votre compte Apple Developer.

Que faire si le projet Flutter se compile dans Xcode mais échoue avec SSH ?

Ne recréez pas immédiatement les certificats. Comparez d’abord l’identité utilisée, le trousseau par défaut, son état déverrouillé et les autorisations accordées au processus non interactif. Une session graphique peut déjà avoir ouvert le trousseau ou accepté une demande d’accès, alors qu’une commande SSH n’a aucun de ces éléments. Corrigez l’environnement avant de modifier le projet.

Runner et les Targets de plugins doivent-ils avoir exactement la même signature ?

Ils doivent utiliser une équipe cohérente et des identifiants compatibles, mais pas nécessairement un Bundle ID identique. Runner, notification extensions, widgets et autres extensions possèdent souvent des App IDs distincts. Pour chaque Target, contrôlez le type de distribution, les capacités activées, le profil associé et les entitlements présents dans l’Archive finale.

Pourquoi l’IPA Flutter est-elle créée alors que la validation des entitlements échoue ?

La création du fichier ne prouve pas que la signature et les autorisations correspondent au profil de distribution. Inspectez l’Archive, l’IPA et les entitlements réellement signés, puis comparez-les au Provisioning Profile utilisé pour chaque Target. Si une capacité est déclarée dans le produit mais absente du profil, corrigez l’App ID ou le profil avant tout nouvel envoi.

Si votre ordinateur actuel permet une signature graphique mais ne peut pas rester disponible pour les tâches iOS, il cumule plusieurs limites : session interrompue, trousseau difficile à restaurer, accès SSH non homogène et concurrence avec vos projets audio, vidéo ou design. Dans ce cas, vous pouvez reproduire le même dépôt sur un Mac distant disposant des droits nécessaires, puis vérifier une Archive, une IPA et un envoi avant de décider.

Consultez les offres de location de Mac mini si vous avez besoin d’un environnement temporaire, ou examinez une commande de Mac mini M4 pour un poste destiné à rester disponible. La location via VpsMesh est surtout pertinente pour un audit de chaîne, une publication ponctuelle ou une période de transition ; pour une charge lourde et stable à long terme, l’achat d’un Mac dédié peut rester plus cohérent.