Stata 19 : quelle version choisir ? Guide de recherche universitaire 2026

Stata distingue trois éditions — Stata/BE, Stata/SE et Stata/MP — avec des positionnements différents selon la taille des données et les besoins de calcul, comme le précise sa page officielle de comparaison des versions. Pour choisir Stata 19, commencez par vérifier les limites que votre jeu de données et vos modèles imposent, puis évaluez si vos commandes bénéficient réellement du calcul parallèle. Si l’édition déjà autorisée suffit et que l’analyse n’exige pas de parallélisme, conservez-la ; ne passez à une autre édition qu’après avoir identifié une limite ou un besoin concret.

Cet article s’adresse aux étudiants et doctorants qui doivent exécuter un travail de cours ou une analyse de mémoire sur Mac.
Il aide les responsables de recherche à établir des critères communs pour l’environnement d’un groupe.
Il s’adresse aussi aux équipes techniques qui doivent distinguer le choix d’édition des questions de licence et de configuration.

Trois éditions, trois critères : que compare réellement Stata 19 ?

Le nom de l’édition n’indique pas, à lui seul, si elle convient à un projet. La décision se construit autour de trois axes : la capacité à traiter les données et les modèles requis, l’éventuel bénéfice du calcul parallèle, puis la reproductibilité des résultats. L’éditeur décrit Stata/BE comme l’édition de base, Stata/SE comme l’édition standard et Stata/MP comme l’édition conçue pour exploiter plusieurs processeurs lorsque les calculs s’y prêtent. Les capacités exactes doivent être vérifiées dans la documentation officielle plutôt que déduites d’un nom commercial.

La comparaison officielle des limites par édition permet de confronter les besoins du projet aux capacités documentées. Elle est préférable à une règle générale comme « choisir l’édition la plus puissante », car une capacité supplémentaire n’a d’intérêt que si le projet en a besoin et si l’autorisation correspondante est disponible.

Il faut aussi séparer trois questions qui sont souvent confondues. Une édition peut permettre de charger un jeu de données sans que cela prouve que le modèle prévu est admissible. Un modèle peut s’exécuter sans que le temps de calcul, la mémoire ou les contrôles de sortie rendent le travail livrable. Enfin, une licence peut être valide sans être utilisable dans le contexte précis prévu par l’établissement. Le choix porte donc sur un ensemble : données, analyses, environnement et autorisation.

Les versions de Stata 19 diffèrent-elles seulement par leur vitesse ?

Non. Le point de départ est la capacité à traiter les données et les modèles requis ; la différence de calcul vient ensuite. L’édition d’entrée n’est pas automatiquement insuffisante pour une recherche universitaire, et l’édition multiprocesseur n’est pas une garantie d’accélération de chaque commande.

Premier axe : vérifier les données et les modèles dans l’édition actuelle

Le premier contrôle consiste à recenser les caractéristiques qui déterminent réellement votre analyse : nombre d’observations, nombre de variables, variables indépendantes nécessaires au modèle, transformations effectuées et éventuels fichiers intermédiaires. Comparez ensuite ces éléments aux limites officielles de l’édition envisagée. N’utilisez pas une limite mémorisée dans un ancien guide : les capacités documentées par édition sont la référence à vérifier.

Cette vérification doit porter sur le projet complet, pas uniquement sur le fichier d’origine. Une analyse peut créer des variables supplémentaires, agréger ou joindre plusieurs sources, puis estimer un modèle dont les besoins diffèrent de ceux d’une simple exploration. Faites l’inventaire des étapes avec le chercheur qui maintient les scripts, ou parcourez les fichiers do avant de conclure qu’une édition convient.

Une vérification minimale dans Stata peut aider à documenter l’environnement et la structure des données. Elle ne remplace pas la lecture du tableau officiel des limites.

about
describe
count

about permet de relever les informations d’installation affichées par Stata ; describe décrit les variables présentes dans les données en mémoire ; count indique le nombre d’observations de l’échantillon chargé. Consignez les informations utiles dans un journal d’audit, en évitant de faire apparaître des données personnelles ou des identifiants confidentiels. Ces commandes ne disent pas à elles seules si un modèle complexe respectera les limites de l’édition : la vérification doit aussi prendre en compte les variables mobilisées par les commandes analytiques.

Attention : « le fichier s’ouvre » et « le projet peut être remis » sont deux conclusions différentes. La seconde suppose que toutes les étapes prévues, y compris les modèles, les sorties et les contrôles de qualité, sont réalisables dans l’environnement autorisé.

La taille des données et le nombre de variables du modèle changent-ils le choix ?

Oui, dès lors que l’un de ces éléments approche ou dépasse une limite de l’édition utilisée. Il faut comparer les besoins constatés à la ligne correspondante dans la table officielle des limites de Stata, plutôt que supposer que toutes les éditions acceptent les mêmes dimensions.

Le nombre de variables dans le fichier ne représente pas toujours le nombre de variables indépendantes requis par une estimation. Certaines commandes, structures de données ou spécifications de modèle peuvent imposer des besoins différents. Pour éviter une décision fondée sur une estimation trop optimiste, relevez les commandes les plus exigeantes dans les scripts, puis vérifiez les caractéristiques effectivement mobilisées. Si l’édition actuelle échoue à cette comparaison, examinez l’édition supérieure pertinente ; si elle convient, passer à une édition plus coûteuse ou plus capacitaire n’apporte pas automatiquement un avantage au projet.

Deuxième axe : établir si les commandes justifient Stata/MP

Stata/MP est à envisager lorsque le flux de travail comprend des calculs adaptés à l’exécution multiprocesseur et que ces calculs représentent un besoin réel. Le nombre de cœurs annoncé pour un Mac ne suffit pas à trancher. Il indique une capacité matérielle, pas le comportement de chaque commande. Les explications de Stata sur Stata/MP et ses performances rappellent que l’intérêt dépend des tâches ; les rapports de performance publiés par l’éditeur présentent des résultats liés à des analyses et environnements précis, pas une promesse de gain uniforme pour n’importe quel projet.

Pour prendre une décision défendable, sélectionnez une analyse représentative : idéalement une commande centrale pour les résultats ou une étape qui retarde effectivement le travail. Exécutez-la sur une copie des données et des scripts dans l’environnement envisagé. Comparez les sorties, le temps nécessaire et la stabilité de la procédure, en gardant le même jeu de données, les mêmes options et une configuration documentée. Si le test ne révèle pas de besoin mesurable ou si les commandes déterminantes ne profitent pas du parallélisme, ne retenez pas MP sur la seule base de la fiche technique de l’ordinateur.

Une régression courante exige-t-elle Stata/MP ?

Pas par principe. Le besoin dépend de la commande utilisée, de la forme du modèle, des données et du temps de calcul acceptable. Une régression qui s’exécute correctement avec l’édition déjà autorisée ne nécessite pas automatiquement Stata/MP ; inversement, une étape de calcul longue peut justifier un test si elle est compatible avec les capacités multiprocesseur documentées.

Le choix doit reposer sur un essai contrôlé, et non sur une comparaison abstraite entre les processeurs d’un Mac. Les rapports officiels de performance peuvent orienter l’évaluation, mais l’expérience du projet reste déterminante. Une analyse de données d’enquête, une estimation répétée dans une boucle et un traitement de fichiers audio ou vidéo associé à des données de recherche ne sollicitent pas nécessairement les mêmes commandes ni les mêmes étapes. Pour les usages créatifs intégrés à une recherche — analyse sonore, annotation audiovisuelle ou traitement de séquences — il faut mesurer la chaîne réellement utilisée, plutôt que présumer que toute la chaîne bénéficie de la même façon du parallélisme.

Troisième axe : protéger la reproductibilité lors d’un changement d’édition

Un changement d’édition ou de configuration doit être traité comme une modification de l’environnement expérimental. Il ne faut ni affirmer que les résultats changeront toujours, ni supposer qu’ils seront nécessairement identiques dans tous les cas. La documentation de Stata explique que des calculs multiprocesseurs peuvent produire de petites différences dans certaines estimations itératives, liées notamment au nombre de processeurs ou à l’ordre des opérations. Cette précision est une raison de contrôler un résultat sensible, pas une preuve que toute analyse produira des valeurs différentes. Consultez la FAQ officielle sur les résultats calculés avec plusieurs processeurs.

Pour préserver une base de comparaison, ne lancez pas le premier essai sur les fichiers de travail partagés. Dupliquez le projet, conservez les données d’origine en lecture seule et distinguez clairement le journal produit par l’édition actuelle de celui produit par l’environnement candidat. Comparez les estimations importantes, les messages d’exécution, les fichiers exportés et les éventuels écarts d’arrondi. Les conclusions doivent être interprétées par rapport aux méthodes du projet et aux critères définis par l’équipe, pas à partir d’un simple « les deux fichiers se ressemblent ».

Le passage de Stata/SE à Stata/MP peut-il affecter la reproduction des résultats ?

Il peut justifier une vérification, en particulier pour certaines estimations itératives ; cela ne signifie pas que le changement entraîne systématiquement des résultats différents. La documentation officielle sur les calculs multiprocesseurs décrit les causes à considérer. Les résultats doivent ensuite être validés sur le projet concerné.

Avant d’adopter un nouvel environnement, comparez les estimations centrales et leurs diagnostics, mais aussi les journaux et les fichiers remis aux collaborateurs. Si une différence apparaît, consignez les versions, la configuration et les commandes en cause, puis demandez au responsable méthodologique de déterminer si elle est acceptable pour l’analyse. Une égalité apparente des sorties ne suffit pas non plus à démontrer que deux environnements sont interchangeables : les scripts, les données, les options et les étapes de production doivent rester comparables.

Quatrième axe : confirmer la compatibilité macOS et la licence

Les exigences du logiciel, la licence et l’accès à un Mac sont trois contrôles distincts. La documentation de Stata indique que Stata 19 peut s’exécuter nativement sur les Mac à puce Apple Silicon ; il est donc possible d’évaluer un environnement Mac sans supposer qu’une couche de traduction est indispensable. Consultez la page officielle dédiée à l’exécution de Stata sur Apple Silicon, puis vérifiez la liste officielle des systèmes macOS compatibles avant de préparer une installation. La liste indiquant actuellement macOS 26 ne permet pas de conclure à une prise en charge, ou à une absence de prise en charge, d’une version ultérieure sans nouvelle vérification.

La compatibilité technique ne vaut pas autorisation. Avant de modifier l’édition ou de déplacer un projet, demandez à l’établissement ou au gestionnaire de licence de confirmer l’édition attribuée, les conditions d’utilisation et les postes ou utilisateurs concernés. Les règles peuvent dépendre du contrat de l’université ; elles ne se déduisent pas du fait qu’un installateur démarre sur un Mac. Pour préparer cette vérification sans la confondre avec un dépannage de licence, consultez aussi les consignes d’installation de Stata sur Mac.

Étape 1 : constituer une fiche de besoin

Notez les données et les modèles requis, les commandes déterminantes, les sorties attendues et l’édition actuellement utilisée. Ajoutez les contraintes de remise : scripts réexécutables, formats d’export, revue par un autre membre de l’équipe ou exécution sur une machine institutionnelle. Cette fiche fait apparaître les besoins du projet sans décider à l’avance qu’une édition supérieure est nécessaire.

Étape 2 : contrôler les limites de l’édition actuelle

Relevez le nombre d’observations et de variables utiles, puis identifiez les besoins propres aux modèles. Confrontez-les à la documentation officielle de comparaison. Si les exigences du projet restent dans les limites, inscrivez ce résultat dans la fiche ; si elles ne correspondent pas, notez précisément la limite rencontrée au lieu de demander une mise à niveau sans justification.

Étape 3 : repérer les étapes qui pourraient profiter du calcul parallèle

Parcourez les do-files et retenez une tâche représentative du traitement réel. Vérifiez si cette tâche relève des usages décrits pour Stata/MP, puis évitez de généraliser le résultat à des commandes qui n’ont pas été testées. Le nombre de processeurs du Mac est une caractéristique de la machine, pas une démonstration de bénéfice pour chaque analyse.

Étape 4 : comparer sur une copie maîtrisée

Dupliquez les scripts et les données autorisées, puis exécutez les étapes choisies dans l’environnement de comparaison. Gardez les options et les entrées constantes. Relevez les journaux, les résultats essentiels et les fichiers produits ; si une différence mérite examen, faites-la valider par la personne responsable de la méthode avant de changer le processus officiel.

Étape 5 : confirmer les conditions de licence et de système

Faites confirmer l’édition utilisable et la portée de la licence par l’établissement. Vérifiez la compatibilité macOS dans les informations officielles à jour. Un système compatible ne crée pas de droit d’utilisation, et une licence valable ne garantit pas que la version de macOS envisagée soit prise en charge.

Étape 6 : consigner une base reproductible

Dans les instructions du projet, enregistrez l’édition de Stata, les informations de système disponibles, l’architecture de la machine et les réglages utiles au calcul. Conservez une copie de référence des scripts et indiquez comment régénérer les tableaux ou fichiers finaux. Ce relevé permet à un collègue de savoir si une différence vient des données, du code ou de l’environnement logiciel.

La règle de décision : conserver, vérifier ou changer d’édition

Appliquez les conditions ci-dessous dans cet ordre :

• Si les données et les modèles tiennent dans l’édition actuellement autorisée et si les commandes n’ont pas de besoin établi de calcul multiprocesseur, conservez cette édition.
• Si un besoin du projet dépasse une limite documentée de l’édition actuelle, vérifiez l’édition supérieure pertinente dans la comparaison officielle et faites confirmer que l’autorisation institutionnelle la couvre.
• Si le temps de calcul est le problème mais que le bénéfice de MP reste incertain, testez d’abord une tâche représentative sur une copie contrôlée ; ne choisissez pas cette édition uniquement parce que le Mac possède plusieurs cœurs.
• Si les résultats doivent être comparés entre environnements, validez les estimations et les sorties après le changement, puis consignez les paramètres avant de partager les résultats.
• Si le système ou la licence ne sont pas confirmés, suspendez la migration du projet et obtenez les validations nécessaires avant d’interpréter un échec comme une incompatibilité de version.

Pour les équipes qui souhaitent évaluer macOS sans acheter immédiatement une machine, un Mac distant peut servir à vérifier un flux de travail sur un environnement réel. Cette option ne remplace ni la validation du contrat de licence ni l’approbation des règles de traitement des données. Les projets contenant des données personnelles ou soumises à des restrictions doivent utiliser une copie dépersonnalisée et respecter les exigences de l’établissement. Les critères généraux d’accès sont présentés sur la page des environnements Mac disponibles.

Le choix le plus prudent reste donc conditionnel : gardez l’édition autorisée tant qu’elle répond aux exigences mesurées ; passez à une autre édition seulement si les limites de données ou les besoins de calcul le justifient. Pour un projet de recherche, le coût d’un changement ne se résume pas au logiciel : il inclut aussi la validation des résultats, l’accord de l’établissement et la documentation à transmettre à l’équipe.

Si le laboratoire fonctionne principalement sous Windows ou Linux, ces postes peuvent rester adaptés aux analyses déjà compatibles, mais ils ne permettent pas à eux seuls de vérifier un flux de travail propre à macOS. Acheter un Mac mobilise un budget matériel pour un besoin parfois limité à une validation ; emprunter une machine peut rendre l’accès incertain ou partagé. Lorsqu’il s’agit seulement de contrôler une analyse Stata sur Mac à court terme, la location d’un Mac auprès de SFTPMAC peut offrir un environnement de test sans achat immédiat. Il convient d’abord de confirmer l’autorisation Stata et les règles de données de l’établissement, puis de consulter les modalités de location avant de décider si cette solution correspond au projet.