Votre application App Designer démarre sur votre poste, mais le laboratoire ne dispose pas d’un Mac pour vérifier ce que recevront vos collègues.
Pour livrer une application de recherche Mac autonome avec MATLAB R2026b, construisez-la sur macOS avec MATLAB Compiler, puis testez-la dans un environnement Mac cible propre ; le destinataire doit généralement disposer du MATLAB Runtime compatible. Si l’usage doit se faire dans un navigateur, évaluez plutôt la voie Web App et ses conditions de serveur.
Cet article s’adresse aux chercheurs qui veulent transmettre un projet App Designer à des collègues sans MATLAB, aux développeurs qui doivent vérifier une version macOS, et au personnel de soutien universitaire chargé de contrôler les dépendances et l’environnement de livraison. Il ne traite ni de l’installation générale de MATLAB ni du dépannage d’une licence défaillante.
SECTION 01 Avant la construction : choisir ce que vous livrez
Le mot « empaqueter » recouvre des livrables qui ne répondent pas au même besoin. Un fichier de projet transmissible, une application autonome et une application Web ne s’installent ni ne s’utilisent de la même façon. Décidez d’abord qui doit utiliser le résultat et dans quel contexte : cela évite de construire un livrable inutilisable pour son destinataire.
La documentation de MathWorks distingue le partage d’une application depuis App Designer de la création d’une application autonome avec MATLAB Compiler. Pour cette dernière, le poste utilisateur n’a généralement pas besoin d’une licence MATLAB pour exécuter l’application, mais il doit disposer du MATLAB Runtime approprié. Vérifiez le parcours de partage des applications App Designer et les conditions de déploiement d’une application autonome avant de choisir votre format.
| Livrable envisagé | À choisir si… | Vérification déterminante |
|---|---|---|
| Projet ou fichiers sources | Le destinataire doit examiner ou modifier le code et possède un environnement MATLAB adapté. | Les fichiers, fonctions, données et dépendances doivent être transmis et documentés. |
| Application de bureau autonome | Le destinataire doit lancer un outil sans ouvrir le projet dans MATLAB. | MATLAB Compiler sert à construire le livrable ; le poste cible doit pouvoir utiliser le Runtime compatible. |
| Web App | Les utilisateurs doivent accéder à l’outil dans un navigateur et l’équipe dispose d’une infrastructure serveur appropriée. | La configuration du serveur et les limites de sécurité doivent être examinées avant le déploiement. |
Cette distinction répond aussi à la question de l’exécution sans MATLAB : une application autonome compilée peut être destinée à des utilisateurs qui n’ont pas MATLAB installé, mais cela ne signifie pas qu’elle fonctionne sans composant d’exécution. Le Runtime et ses conditions d’installation font partie du plan de livraison, comme le décrit la documentation consacrée à MATLAB Runtime.
Arbre de décision pour sélectionner la voie
- Si vos collègues doivent modifier l’interface ou le code dans MATLAB, transmettez le projet et ses dépendances ; ne présentez pas l’application compilée comme un substitut au code source.
- Si les destinataires doivent lancer un outil de bureau sans ouvrir MATLAB, et si votre équipe peut construire sur macOS avec MATLAB Compiler, choisissez l’application autonome, puis prévoyez le Runtime et un essai sur le Mac cible.
- Si l’accès par navigateur est indispensable et que vous pouvez satisfaire les exigences de serveur, étudiez la Web App ; sinon, revenez à une application de bureau ou au partage du projet.
- Si vous n’avez aucun Mac disponible pour construire ou vérifier le livrable, ne concluez pas que l’application est prête sur la seule base d’une compilation effectuée ailleurs : trouvez un environnement macOS de validation avant la remise.
SECTION 02 Jalon de préparation : rendre le projet reproductible
Avant d’ouvrir l’outil de construction, créez une copie de travail restaurable. Conservez le projet d’origine intact, puis rassemblez les fichiers utilisés par l’interface, les fonctions appelées, les données nécessaires aux exemples et les éléments chargés à l’exécution. Une application peut se construire alors que son flux scientifique reste incomplet parce qu’un fichier de configuration ou une ressource externe manque.
| Élément à inventorier | Exemple de contrôle | Risque en cas d’oubli |
|---|---|---|
| Fichier principal App Designer | L’application attendue s’ouvre et les callbacks utilisés sont présents. | Vous construisez le mauvais point d’entrée ou une version incomplète. |
| Fonctions et code auxiliaire | Les appels sont repérés, y compris ceux qui ne sont pas déclenchés au démarrage. | Une fonction peut manquer lorsque l’utilisateur choisit une action précise. |
| Données et ressources externes | Les fichiers nécessaires au test sont copiés dans un dossier de test maîtrisé. | L’application démarre, mais échoue dès qu’elle charge un fichier absent. |
| Boîtes à outils et fonctions spécialisées | Les dépendances attendues sont vérifiées dans le projet et dans l’environnement de construction. | Une fonction indispensable peut ne pas être disponible dans le livrable. |
| Réglages et chemins d’accès | Les chemins absolus propres au poste de développement sont identifiés. | Le logiciel peut chercher des données dans un dossier inaccessible sur le Mac cible. |
Ne confondez pas « le projet s’ouvre sur mon poste » et « le projet est prêt à être livré ». Recensez aussi les comportements peu visibles : fichiers créés à l’export, préférences utilisateur, sélection de dossier, messages d’erreur et ressources chargées à la demande. La documentation de MATLAB Compiler présente une procédure d’analyse des dépendances ; servez-vous de l’analyse des dépendances pour repérer les éléments que vous devez examiner plutôt que de supposer que tout sera détecté sans vérification.
Avant la construction, vérifiez que votre compte et celui de l’équipe disposent des droits nécessaires pour utiliser MATLAB Compiler dans le cadre prévu. Cela relève des conditions de licence de votre établissement : ne déduisez pas de la présence d’un logiciel sur un poste de laboratoire que son utilisation sur un Mac distant est automatiquement couverte. Faites confirmer ce point par le responsable des licences ou le soutien informatique, séparément du test technique.
Enfin, notez l’environnement de construction utilisé et conservez le journal de génération avec la copie du projet. Le guide des exigences système MATLAB pour Mac doit servir à vérifier la compatibilité publiée pour la version utilisée, le système et l’architecture du Mac. La compatibilité évoluant selon les versions prises en charge, ne remplacez pas cette vérification par une règle générale fondée sur le seul nom du processeur.
Attention : une génération terminée sans message bloquant prouve seulement que l’outil a produit un livrable. Elle ne prouve ni que les données scientifiques sont correctement traitées, ni que l’application démarre sur un Mac propre, ni que votre établissement autorise la configuration choisie.
SECTION 03 Jalon de construction : produire l’application sur macOS
Pour construire l’application de recherche destinée au Mac, ouvrez le projet dans l’environnement macOS retenu et choisissez le parcours de génération d’application autonome d’App Designer. Le point d’entrée doit être le fichier .mlapp réellement destiné aux utilisateurs, et non une ancienne copie conservée pour un test. Avant de lancer la compilation, vérifiez le nom du livrable, l’emplacement de sortie et les fichiers que vous souhaitez inclure.
Pendant le processus, ne réduisez pas l’examen à la dernière ligne du journal. Relevez les fonctions que l’analyse n’a pas résolues, les dépendances qui semblent absentes et les ressources incorporées ou référencées à l’extérieur. À chaque avertissement, associez une décision : corriger le code, ajouter explicitement un fichier, confirmer que l’élément n’est pas nécessaire, ou consigner une limite connue. La documentation sur les limites de la compilation est particulièrement utile pour vérifier qu’une fonctionnalité employée par le projet peut réellement être compilée et déployée.
Première passe de génération
Procédez dans cet ordre :
- Ouvrez la copie de travail restaurable et vérifiez que son interface correspond à la version que vous souhaitez livrer.
- Déclenchez la génération autonome depuis App Designer, en sélectionnant le fichier d’application principal comme entrée.
- Examinez les résultats de l’analyse des dépendances ; ajoutez ou corrigez les éléments nécessaires au lieu d’ignorer les avertissements.
- Conservez le journal de construction, le nom et l’emplacement du livrable, ainsi que la liste des fichiers transmis séparément.
- Relancez la construction après chaque modification de dépendance, puis comparez les journaux pour comprendre ce qui a changé.
La génération peut révéler des problèmes différents : fonction introuvable, donnée non incluse, chemin codé en dur ou composant incompatible avec la compilation. Traitez-les séparément. Une fonction manquante appelle une vérification des dépendances du code ; un fichier de données absent demande de clarifier s’il doit être incorporé ou livré à part ; une limite de compilation exige de revoir la conception ou le parcours de déploiement. Recommencer la génération sans consigner ces distinctions rend le diagnostic et la reproduction du résultat plus difficiles.
SECTION 04 Jalon de validation locale : comparer l’application aux résultats attendus
L’application produite doit être installée et lancée dans l’environnement de construction, mais ce premier essai n’est qu’un contrôle préliminaire. Il permet de détecter des erreurs évidentes de démarrage ou d’interface ; il ne démontre pas que le livrable fonctionnera sur une autre machine ni qu’il reproduira correctement l’analyse scientifique.
Préparez un petit jeu d’essai synthétique ou correctement désensibilisé, avec un résultat de référence obtenu depuis le projet MATLAB d’origine. Évitez d’utiliser des données identifiantes dans un test de livraison. Le cas choisi doit couvrir le chemin réellement utilisé par le laboratoire : import, paramètres, exécution du traitement, affichage et export. Pour une application audio ou vidéo, examinez également le chargement d’un échantillon, le comportement des commandes de lecture ou de prévisualisation et la sauvegarde du résultat ; pour un outil de conception ou de traitement d’image, contrôlez la sélection des ressources, les interactions graphiques et l’export. Ces parcours créatifs peuvent échouer sur un détail d’interface alors que le calcul central fonctionne.
| Fonction à contrôler | Action de validation | Preuve à conserver |
|---|---|---|
| Démarrage et interface | Lancez l’application compilée et parcourez les écrans utilisés dans le flux courant. | Capture ou note de version, avec les anomalies observées. |
| Import des données | Chargez un fichier d’essai depuis un emplacement différent de celui du développeur. | Type de fichier, chemin de test et confirmation de lecture. |
| Analyse | Rejouez une procédure de référence avec les mêmes paramètres que dans le projet d’origine. | Paramètres utilisés et comparaison aux résultats de référence. |
| Erreurs et cas incomplets | Testez une entrée invalide ou une ressource manquante, sans exposer de données sensibles. | Message obtenu et comportement attendu de l’application. |
| Export | Enregistrez le résultat dans un dossier choisi par l’utilisateur, puis rouvrez-le. | Fichier exporté et contrôle de son contenu. |
Comparez les sorties avec des critères adaptés à votre méthode : valeurs calculées, tableaux, fichiers générés ou comportement visuel. Ne déclarez pas une équivalence scientifique à partir du seul fait que deux interfaces affichent des résultats. Si l’application utilise des calculs qui dépendent de paramètres, de données externes ou de choix de l’utilisateur, enregistrez ces entrées pour que le test soit rejouable.
SECTION 05 Jalon Mac cible : valider dans un environnement séparé
Le contrôle local ne remplace pas l’essai sur le Mac destiné à l’utilisateur. Installez le Runtime requis en suivant les instructions d’installation de MATLAB Runtime, puis vérifiez les exigences publiées pour la combinaison de version MATLAB et de macOS visée. Le livrable doit être testé dans un environnement suffisamment séparé de celui qui a servi à le construire pour repérer les dépendances qui n’existent que sur le poste développeur.
Le destinataire qui n’a pas MATLAB peut donc exécuter une application autonome conçue pour être déployée avec Runtime, sous réserve que l’environnement soit compatible et que les composants nécessaires soient disponibles. En pratique, le contrôle ne se limite pas à demander « l’application s’ouvre-t-elle ? » : vérifiez le lancement, le chargement du jeu d’essai, les chemins de fichiers, les ressources externes, les interactions graphiques et l’export. Consignez aussi les conditions précises qui ont provoqué un échec, afin que le laboratoire puisse distinguer un problème de livraison d’un changement apporté aux données.
Réalisez ce contrôle avec une copie représentative du projet, jamais avec les seules données présentes dans le dossier du développeur. Si des fichiers sont fournis séparément, copiez-les comme le ferait le destinataire et suivez les instructions de livraison à la lettre. Lorsque l’application s’appuie sur un répertoire de travail, vérifiez ce qui se passe si l’utilisateur choisit un autre dossier ; lorsque les résultats sont exportés, vérifiez que le chemin n’est pas limité à un emplacement propre à votre compte.
Gardez une trace courte, mais exploitable : version du livrable, environnement testé, présence du Runtime, procédure suivie, fichiers d’essai et résultat de chaque étape. Ne présentez pas les exigences système officielles comme une preuve de validation de votre projet particulier. Les pages officielles décrivent les environnements pris en charge ; seule votre exécution du flux représentatif établit que votre application fonctionne avec les dépendances et les données que vous comptez livrer.
SECTION 06 Choix de livraison : application de bureau, projet ou Web App
La Web App constitue une voie distincte, pas une variante automatiquement plus simple de l’application autonome. Elle implique une configuration serveur et des limites de déploiement ; MathWorks décrit les éléments propres au déploiement de Web Apps et les précautions de sécurisation des Web Apps. La documentation y associe un déploiement dans un environnement de confiance, notamment sur un réseau interne de confiance : ne transformez pas cette option en service accessible publiquement sans examiner séparément les exigences de sécurité.
Pour trancher, partez des utilisateurs et des moyens réels de votre équipe. Si vos collègues doivent modifier l’application, livrez le projet avec les dépendances et instructions adaptées. S’ils veulent seulement utiliser un outil de bureau et peuvent installer le Runtime, privilégiez l’application autonome et validez-la sur le Mac cible. Si l’accès par navigateur est requis, n’optez pour la Web App que si l’organisation peut fournir et administrer l’infrastructure conforme aux conditions documentées.
Si votre laboratoire ne possède pas de Mac, vous pouvez examiner un environnement macOS distant pour construire et valider le livrable, mais ne présumez ni de la compatibilité d’un projet non testé ni de la couverture de votre licence. Avant de louer une machine, faites confirmer vos droits d’utilisation et définissez les essais que vous devez exécuter. Vous pouvez consulter les conditions des environnements Mac proposés par VPSNIX, puis vérifier les offres et modalités tarifaires si cet usage temporaire correspond à votre calendrier.
Une machine distante est surtout pertinente lorsque vous avez besoin d’un environnement macOS pour une période circonscrite : construire le paquet, installer le Runtime et refaire le parcours d’acceptation. Elle n’est pas nécessairement le meilleur choix si votre laboratoire exige une machine locale permanente, un accès physique à des périphériques particuliers ou une charge soutenue qui justifie un achat et une administration internes. Dans tous les cas, comparez le coût d’accès au Mac avec les contraintes de préparation, d’autorisation et de transfert de vos données ; le tarif ne remplace pas la vérification technique.
Au moment de remettre l’application, transmettez le livrable, les instructions d’installation du Runtime, les fichiers de données nécessaires, les limites connues et les résultats de validation. Pour un test scientifique, ajoutez le jeu d’essai autorisé et les paramètres qui permettent de rapprocher la sortie de la référence. Si vous ne disposez aujourd’hui que d’un poste Windows ou Linux, ces systèmes peuvent rester adaptés à d’autres tâches du laboratoire, mais ils ne démontrent pas à eux seuls le fonctionnement de l’application macOS. Un accès temporaire à un Mac via VPSNIX peut alors compléter votre parc existant pour la construction et l’acceptation, à condition que votre licence et vos exigences de sécurité l’autorisent.