La documentation Microsoft confirme qu’Excel pour Mac prend en charge la création et l’exécution de macros VBA (aperçu de VBA pour Office sur Mac). Cela ne garantit pas qu’un classeur écrit sous Windows fonctionnera à l’identique. Cette semaine, testez une copie du fichier avec une tâche de recherche représentative ; si une dépendance ou un résultat échoue, conservez l’exécution sous Windows jusqu’à correction et nouvelle validation.
Cet article s’adresse aux personnes qui doivent réexaminer sur Mac un classeur transmis par un utilisateur Windows, aux équipes de recherche qui veulent transférer un flux d’analyse entre plateformes et aux responsables informatiques qui définissent les règles d’acceptation d’un environnement.
Une prise en charge de VBA ne vaut pas validation du classeur
Pour évaluer la compatibilité multiplateforme d’Excel VBA, séparez quatre questions : le fichier s’ouvre-t-il, la macro est-elle autorisée à s’exécuter, le traitement va-t-il jusqu’au bout et les résultats sont-ils conformes ? Une réponse positive à la première question ne prouve rien sur les suivantes. De même, l’absence de message d’erreur ne confirme pas qu’une analyse scientifique a produit les mêmes valeurs.
La documentation Microsoft décrit bien VBA dans Office pour Mac et fournit des procédures pour travailler avec les macros dans Excel for Mac. Elle ne certifie pas pour autant chaque fichier conçu sous Windows : les appels système, les objets utilisés, les connexions externes et les chemins d’accès doivent être vérifiés dans le contexte réel du classeur. C’est pourquoi un test d’ouverture seul est un critère insuffisant.
Avant de commencer, conservez le fichier d’origine intact et créez une copie de test. Choisissez une tâche que vous pouvez répéter avec les mêmes données d’entrée, puis notez les prérequis, les actions attendues et les résultats à comparer. Si le classeur contient des données sensibles, n’utilisez pas une copie dans un environnement non approuvé : vérifiez d’abord les règles de votre établissement et les autorisations applicables.
Une macro démarre-t-elle réellement sur Mac ?
Un classeur peut s’ouvrir sans que son code soit autorisé à s’exécuter. Pour distinguer ces situations, relevez d’abord la version d’Excel, la provenance du fichier, le message affiché à l’ouverture et le comportement du bouton ou de la commande censée lancer la macro. Microsoft décrit les commandes de création et de gestion des macros dans sa procédure dédiée à Excel pour Mac.
Procédez ensuite à un lancement contrôlé. Sur la copie, utilisez la commande prévue par le classeur, puis observez si le traitement démarre, s’arrête ou semble ne rien faire. Si la macro est liée à un bouton, testez également la commande depuis l’interface prévue : l’affichage du bouton ne prouve pas que l’action qui lui est associée est disponible. Microsoft explique séparément comment associer une macro à un formulaire ou à un bouton de contrôle, ce qui aide à séparer un problème d’interface d’un problème de code.
Consignez chaque observation avant de modifier des réglages. Un changement de sécurité peut transformer un blocage explicite en lancement autorisé, mais il ne démontre pas que le code fonctionne correctement. Vérifiez les réglages de macro appliqués à Excel pour Mac à partir de la documentation Microsoft sur leur activation et leur désactivation. Si l’appareil est géré par l’établissement, confrontez ces réglages aux règles locales : ne désactivez pas les protections et ne contournez pas une politique universitaire pour faire passer un test.
Critère de passage : la macro démarre avec les réglages autorisés, l’action attendue est effectivement lancée et vous pouvez décrire les conditions dans lesquelles le test a été effectué. Un message de blocage ou un bouton inactif signifie que l’exécution n’est pas encore validée.
Les appels Windows et les objets utilisés expliquent-ils l’arrêt ?
Si la macro démarre puis échoue à une étape précise, repérez l’action immédiatement précédente plutôt que de conclure à une incompatibilité générale. Les pistes fréquentes à examiner sont les opérations sur les feuilles et les classeurs, les objets liés à l’interface, les modules complémentaires, les composants externes et les instructions qui interagissent avec le système d’exploitation. Leur présence est un indice à vérifier, pas une preuve que le classeur est inutilisable sur Mac.
Recherchez dans le code les appels externes, les références à des fichiers ou dossiers, les commandes propres à Windows et les noms d’objets créés par des modules complémentaires. Si le classeur utilise une connexion de données, vérifiez aussi si le pilote ou la source concernée est pris en charge dans la configuration visée. Microsoft publie une liste consacrée aux pilotes ODBC compatibles avec Excel pour Mac. Sa présence dans une liste ne valide toutefois pas votre connexion particulière : il reste nécessaire de tester le pilote, l’accès au serveur et les paramètres réellement utilisés par l’équipe.
Pour isoler l’origine de l’échec, relancez une seule opération à la fois sur la copie de test et consignez la ligne, l’action ou l’accès concerné. Faites confirmer toute modification du code par la personne qui le maintient, puis répétez les tests Windows et Mac avec les mêmes entrées. Une correction qui supprime l’erreur sur Mac peut aussi modifier une étape de calcul ou d’export : elle doit donc être vérifiée sur les deux plateformes.
Critère de passage : chaque dépendance requise est disponible et autorisée sur le Mac cible, ou bien l’équipe a documenté une modification contrôlée avec ses effets sur les autres systèmes. En cas de dépendance Windows indispensable et sans solution validée, gardez Windows comme chemin d’exécution.
Les fichiers, chemins et sources de données sont-ils accessibles ?
Une macro peut s’exécuter sans pouvoir lire le fichier d’entrée ou écrire le résultat à l’emplacement prévu. Vérifiez séparément le chemin construit par le code, le dossier partagé, le nom du fichier, les droits d’accès et les messages de confidentialité ou d’autorisation. Ne confondez pas un refus d’accès avec une erreur de logique dans la macro : les deux problèmes demandent des corrections différentes.
Notez les chemins utilisés en pratique, les fichiers que la macro tente d’ouvrir et ceux qu’elle produit. Remplacez, pour le test, les données sensibles par un échantillon autorisé et contrôlé si cette substitution conserve le comportement pertinent. Comparez ensuite le résultat attendu à la sortie réellement créée, sans accorder d’accès général à des dossiers qui ne sont pas nécessaires au traitement.
Pour les connexions de données, contrôlez précisément la source, le pilote, l’authentification et les opérations de rafraîchissement. Les fonctions disponibles peuvent dépendre de la version d’Excel et du type de source ; la documentation Microsoft sur les sources Power Query selon les versions d’Excel permet de vérifier les limites documentées. Traitez cette information comme un filtre préalable, pas comme une confirmation que les identifiants, la configuration réseau ou la requête de votre laboratoire fonctionneront.
Critère de passage : la macro lit les entrées prévues, écrit les sorties à l’endroit convenu et ne demande pas de permissions élargies non justifiées. Si un accès est bloqué, consignez-le et faites valider le réglage par l’équipe compétente avant toute reprise.
Des résultats identiques confirment-ils le traitement scientifique ?
Un traitement sans interruption peut tout de même donner un résultat différent. Pour la validation des classeurs de recherche, figez un échantillon d’entrée autorisé et identifiez les cellules clés, les totaux, les fichiers exportés et les transformations intermédiaires à comparer. Utilisez les mêmes données et les mêmes paramètres sur Mac et Windows. Notez les valeurs obtenues et l’étape où la première différence apparaît.
N’exigez pas une comparaison visuelle approximative lorsque les données permettent un contrôle plus direct. Comparez les valeurs calculées, les lignes exportées, les libellés, les dates, les unités et les filtres appliqués. Si le classeur comporte des étapes aléatoires, des arrondis ou des dépendances à des données externes, documentez-les : une divergence peut être liée à ces paramètres et ne doit pas être attribuée au seul système d’exploitation sans vérification.
Répétez le traitement avec les mêmes conditions pour vérifier qu’il produit une sortie cohérente. Si deux exécutions sur la même plateforme donnent déjà des résultats différents, le test ne permet pas encore de comparer les systèmes. Dans ce cas, stabilisez d’abord l’entrée et les paramètres, ou demandez à la personne responsable de l’analyse de préciser les résultats attendus.
Critère de passage : les indicateurs retenus et les fichiers de sortie respectent les critères définis par l’équipe. Toute différence non expliquée, même si la macro s’exécute et affiche une feuille sans erreur, bloque la validation scientifique. Ne remplacez pas l’examen des résultats par la seule constatation que le code est arrivé au bout.
Une procédure de validation qui laisse des preuves exploitables
Pour que la décision soit réutilisable par vos collègues, consignez le test comme un petit dossier de transfert :
- Préparez une copie maîtrisée. Conservez l’original, identifiez le fichier testé et utilisez des données dont l’usage est autorisé.
- Décrivez les conditions. Notez la plateforme, la version d’Excel, les réglages de sécurité et les prérequis signalés par l’équipe.
- Reproduisez une tâche représentative. Gardez les mêmes entrées, les mêmes paramètres et les mêmes actions sur Mac et Windows.
- Localisez chaque écart. Distinguez blocage de sécurité, erreur de code, accès aux fichiers, dépendance externe et différence de résultat.
- Vérifiez les sorties. Comparez les cellules importantes, les agrégats et les fichiers produits, puis répétez si le résultat dépend d’un traitement non déterministe.
- Rendez une décision conditionnelle. Indiquez ce qui est validé, ce qui doit être corrigé et quelle plateforme reste requise tant que le test n’est pas concluant.
Ces étapes évitent qu’un collègue interprète « le fichier s’ouvre » comme « le protocole est reproductible ». Elles permettent également de revenir sur une décision après une mise à jour d’Excel, un changement de pilote ou une modification du classeur.
Choisir la plateforme à partir des preuves obtenues
Le tableau ci-dessous traduit les observations en décision opérationnelle. Une validation partielle n’est pas un feu vert : elle précise seulement quelle partie du flux peut être utilisée sur Mac.
| Option | Conditions observées | Décision pour le groupe |
|---|---|---|
| Utiliser le classeur sur Mac | Macro autorisée, opérations requises disponibles, entrées et sorties accessibles, résultats conformes aux critères de l’équipe | Accepter l’usage sur le Mac testé et conserver le dossier de validation |
| Modifier puis retester | Échec isolé et explicable, modification examinée, critères de sortie encore vérifiables | Autoriser un nouveau test sur les deux plateformes avant de diffuser le classeur corrigé |
| Conserver l’exécution sur Windows | Dépendance indispensable non disponible, accès impossible ou résultats divergents sans explication | Garder Windows comme environnement d’exécution et documenter cette contrainte |
| Reporter la décision | Échantillon inadéquat, conditions non reproductibles, règles de sécurité ou autorisations à clarifier | Ne pas utiliser le classeur pour produire des résultats de recherche avant résolution |
Si votre laboratoire dispose déjà d’un Mac, cet essai local peut suffire pour un poste et une configuration déterminés. Pour une équipe qui doit reproduire le test à distance, un Mac hébergé peut servir de voie de vérification, mais ne remplace ni la licence des logiciels requis ni l’approbation institutionnelle pour les données. Vous pouvez consulter les informations de VMSPIN sur l’environnement Mac à distance et vérifier les modalités de tarification avant de décider si un accès temporaire convient à votre protocole.
Cette option ne convient pas à tous les usages : si le classeur doit tourner durablement sur un poste stable, dépend d’un périphérique physique ou traite des données qui ne peuvent pas sortir de l’environnement approuvé, mieux vaut privilégier une configuration gérée par votre établissement. À l’inverse, lorsque le manque de Mac empêche simplement une validation ponctuelle, l’environnement Windows seul ne permet pas de confirmer le comportement sous macOS ; acheter une machine pour un essai limité peut aussi mobiliser un budget sans garantir que le classeur sera compatible.
Si votre groupe n’a pas de Mac de test, commencez par préparer une copie sans données sensibles et vérifiez les règles de partage avant tout transfert. Vous pourrez ensuite évaluer si louer un Mac via VMSPIN est adapté à cette validation ciblée, en tenant compte des dépendances, des accès autorisés et du niveau de contrôle requis. La conclusion doit rester fondée sur les preuves : Mac validé, modification à retester ou exécution Windows maintenue.