J'ai donc trouvé la réponse. Tout d'abord, vous pouvez avoir une meilleure idée de la façon dont FlexBuilder compile votre application en ajoutant un -dump-config = C: \ myConfig.xml aux arguments de compilation dans FlexBuilder. Cela génère un fichier xml contenant les paramètres de configuration utilisés dans l'étape de compilation. Vous pouvez également utiliser ce fichier comme argument pour compc ou mxmlc si vous le souhaitez. En savoir plus à ce sujet here ...
Mais, voici ce qui a réellement résolu mon problème. J'utilisais l'ancien SDK Flex standard installé sur notre serveur d'intégration pour compiler mes applications en utilisant Ant. C'est le SDK gratuit que vous pouvez télécharger sur le site d'Adobe. J'ai ensuite pris le répertoire FlexBuilder de ma machine locale et l'ai copié sur le serveur d'intégration et j'ai pointé mon script de construction pour utiliser cette version du SDK (et changé la variable d'environnement de mon chemin). Lorsque j'ai compilé en utilisant la version FlexBuilder du SDK, tout s'est bien passé et les bugs étranges que je voyais dans mon application ont disparu.
Bien sûr, assurez-vous d'utiliser la même version du SDK pour vos builds automatisés que vous utilisez pour construire localement.
Je ne peux que convenir qu'il est extrêmement important d'avoir les mêmes versions de flex sdk sur le serveur d'intégration et le développement local. Nous avons eu de gros problèmes à compiler un projet 3.1 sur une version 3.2 du sdk (il y avait des problèmes avec l'inclusion de fichiers swc) – Mauli