ATLAS.ti 26 Project Cloud convient-il à la collaboration d’équipe : checklist de validation 2026

Un projet ATLAS.ti se retrouve modifié sur un Mac et un PC, sans indication claire de la version à conserver.

La solution la plus rapide est de retenir cette règle : ATLAS.ti 26 Project Cloud convient à la reprise individuelle entre appareils et au partage asynchrone, mais ne doit pas servir à modifier simultanément un même projet. Pour le codage en temps réel, privilégiez ATLAS.ti Web. Pour l’analyse de bureau, la fusion de projets ou l’accord entre codeurs, conservez un projet maître unique et utilisez le processus de distribution puis de fusion documenté par ATLAS.ti.

Cet article s’adresse aux responsables d’études qualitatives qui doivent définir un projet maître, des droits et des livrables. Il concerne aussi les étudiants et codeurs travaillant entre Mac et Windows, ainsi que les équipes informatiques universitaires chargées d’évaluer les licences, le stockage et un Mac distant.

Point vérifié le 7 septembre 2026 : le manuel officiel ATLAS.ti 26 pour Mac indique la version 26.1.1. Project Cloud est encore présenté comme une fonction Beta. Les limites de synchronisation et de visibilité entre le bureau et le Web doivent donc être contrôlées avant chaque déploiement.

[ SECTION_01 ] Les quatre voies ne répondent pas au même besoin

Le choix ne dépend pas seulement du système d’exploitation. Il dépend surtout de la simultanéité attendue, du type d’analyse et de la manière dont les données doivent revenir dans le projet principal.

Voie de collaboration	Usage approprié	Limite déterminante	Validation minimale
Project Cloud	Reprendre seul un projet entre Mac et Windows	Deux appareils ne doivent pas modifier simultanément le même projet	Télécharger la version la plus récente, travailler seul, puis téléverser
ATLAS.ti Web	Codage partagé et travail synchronisé dans le navigateur	Les fonctions et projets Web ne sont pas identiques à ceux du bureau	Créer un projet test et vérifier les fonctions indispensables
Projet distribué puis fusionné	Répartir le codage entre plusieurs personnes	Les copies doivent provenir d’un projet maître cohérent	Tester les identités, les identifiants d’entités et les conflits
Mac distant avec version bureau	Utiliser l’analyse de bureau sans acheter un Mac	Dépendance à la connexion, à la licence et au transfert des fichiers	Ouvrir un projet désensibilisé, analyser, exporter et nettoyer la session

La documentation officielle présente Project Cloud comme un mécanisme de stockage et de synchronisation d’un projet de bureau, non comme un espace de coédition simultanée. La documentation officielle de Project Cloud doit être la référence pour vérifier l’état de la version, l’envoi et le téléchargement.

Pour les exigences système, l’équipe doit également consulter les prérequis officiels d’ATLAS.ti 26 pour Mac. Une application qui se lance n’est pas encore un environnement validé : il faut aussi contrôler la licence, l’ouverture du projet, l’export et la restitution des résultats.

[ SECTION_02 ] Project Cloud : une bonne reprise individuelle, pas un éditeur partagé

Project Cloud peut-il permettre à plusieurs personnes de modifier le même projet en même temps ?

Non, ce n’est pas une base sûre pour ce scénario. Le manuel officiel précise que deux appareils ne doivent pas éditer simultanément le même projet Project Cloud. La conséquence est concrète : si un Mac et un PC possèdent chacun des modifications non téléversées, il faut arrêter le codage et rétablir une version de référence avant toute nouvelle intervention.

Scénario : une personne passe du Mac à Windows

Ce cas est adapté à Project Cloud si une seule personne travaille à la fois. Le projet reste un projet de bureau, avec une copie locale sur l’appareil utilisé. La synchronisation ne dispense donc pas de vérifier l’ordre des versions.

Procédure de validation :

1. Ouvrez Project Cloud sur le premier appareil.
2. Vérifiez que la copie proposée est la plus récente avant de l’ouvrir pour modification.
3. Notez l’appareil utilisé et l’heure de début dans un journal de travail.
4. Travaillez sur une seule session active.
5. Enregistrez les modifications et téléversez le projet avant de quitter.
6. Sur le second appareil, attendez la fin du téléversement puis téléchargez la version disponible.
7. Ouvrez quelques documents, codes, mémos et groupes afin de vérifier que le contenu attendu est présent.

Le critère de réussite est simple : chaque changement possède un propriétaire identifiable et chaque reprise commence sur la dernière version disponible. Le critère d’arrêt est tout aussi important : deux appareils affichent des changements locaux non envoyés, ou une alerte indique que les versions ne correspondent plus. Dans ce cas, il ne faut pas tenter de résoudre le conflit en continuant à coder.

Comment collaborer entre Mac et Windows avec ATLAS.ti 26 ?

Pour une personne seule, la méthode consiste à alterner les appareils en respectant le cycle téléchargement, travail, envoi. Pour une équipe, cette logique ne suffit plus : chaque membre doit recevoir une copie de travail issue du même projet maître, avec des consignes de nommage et une date de retour. Il ne faut jamais interpréter plusieurs copies indépendantes comme une fusion automatique.

[ SECTION_03 ] Le travail asynchrone exige un projet maître et une chaîne de retour

Dans un petit groupe, la distribution de copies peut convenir à une phase de codage séparée. Elle exige cependant une gouvernance précise. Le responsable doit conserver une copie originale en lecture seule, puis créer une copie de travail à partir de cette base.

Le processus officiel de travail en équipe décrit cette logique de distribution et de récupération. La documentation de transfert de projet aide à vérifier le mode d’échange, mais l’équipe doit aussi définir ses propres règles de conservation.

Avant de distribuer un échantillon désensibilisé, documentez :

• le nom du projet maître et son responsable ;
• l’identité de chaque codeur ;
• le lot de documents attribué ;
• les codes et mémos qui ne doivent pas être modifiés ;
• le format de retour attendu ;
• le dossier de dépôt et la personne chargée de la fusion ;
• la règle applicable si un membre travaille sur un document déjà traité.

La validation doit reproduire une vraie boucle, même avec un petit échantillon :

1. Le responsable conserve l’original en lecture seule.
2. Il prépare une copie de travail avec les documents nécessaires.
3. Chaque codeur reçoit une copie nommée sans ambiguïté.
4. Les membres codent uniquement leur lot.
5. Ils retournent leur fichier sans remplacer le projet maître.
6. Le responsable effectue une fusion test.
7. Le groupe compare les documents, les codes, les mémos et les identités.

Un projet n’est pas validé parce que les fichiers sont arrivés dans le même dossier. Il est validé lorsque le responsable peut savoir qui a codé quoi, sur quelle base, et avec quel résultat après fusion.

[ SECTION_04 ] ATLAS.ti Web est la voie à examiner pour le codage simultané

ATLAS.ti Web peut-il être poursuivi directement dans la version de bureau ?

Il ne faut pas le présumer. Selon la limite officielle définie dans le périmètre de validation de cette version, les projets Project Cloud du bureau et les projets ATLAS.ti Web ne sont pas actuellement visibles l’un dans l’autre. Le passage entre les deux environnements doit donc être traité comme un transfert contrôlé, et non comme une synchronisation transparente.

La documentation officielle sur le transfert de projets doit être consultée pour vérifier les opérations d’importation et d’exportation. L’équipe doit aussi relever les éventuelles modifications de format ou de visibilité après transfert.

ATLAS.ti Web devient pertinent lorsque plusieurs personnes doivent coder dans un même espace accessible par navigateur. Avant de l’adopter, testez un projet contenant :

• quelques documents textuels désensibilisés ;
• un jeu de codes et de mémos ;
• une tâche de codage attribuée à plusieurs membres ;
• une exportation destinée à l’analyse ou à l’archivage ;
• un résultat qui doit ensuite être repris dans le processus de recherche.

Si l’étude dépend d’une fonction exclusivement disponible dans la version de bureau, le groupe doit éviter un fonctionnement hybride improvisé. Une méthode plus sûre consiste à séparer les phases : codage partagé dans Web, export contrôlé, puis analyse de bureau sur un projet maître identifié. Le responsable doit écrire cette transition dans le protocole afin qu’un export ne soit pas confondu avec une synchronisation continue.

[ SECTION_05 ] La fusion et l’accord entre codeurs nécessitent des copies comparables

Comment fusionner les projets après un codage à plusieurs ?

La fusion commence avant la distribution. Tous les codeurs doivent partir d’un projet commun contenant les mêmes documents, les mêmes codes et une structure connue. Si chacun crée ses propres documents ou reconstruit sa propre hiérarchie de codes, l’analyse des divergences devient beaucoup plus difficile.

La documentation officielle sur la fusion des projets d’équipe recommande de contrôler les identités, les entités et les conflits. Pour Mac, la page consacrée à la fusion et à l’analyse de cohérence doit compléter cette vérification.

Le responsable doit rechercher quatre signaux :

1. les documents apparaissent en double ;
2. les codes possèdent des identifiants ou des libellés incohérents ;
3. l’identité du codeur est conservée dans les éléments fusionnés ;
4. le rapport de conflit permet de distinguer une modification réelle d’une duplication.

Pour une analyse de cohérence entre codeurs, le projet maître doit produire des copies indépendantes. Les membres ne doivent pas repartir de projets vierges ni réimporter manuellement les mêmes documents. La présentation officielle de l’accord entre codeurs fournit le cadre à vérifier avant l’étude réelle.

Un essai de fusion sur des entretiens désensibilisés est indispensable. Le résultat attendu n’est pas seulement l’absence de message d’erreur. Il faut pouvoir identifier les codages de chaque personne, conserver les documents sans doublon et produire les éléments nécessaires à la comparaison.

[ SECTION_06 ] Les entretiens sensibles et les fichiers multimédias imposent une décision séparée

Project Cloud ne doit pas être approuvé pour des entretiens sensibles uniquement parce que l’application fonctionne. La décision doit suivre la classification des données, l’approbation éthique de l’établissement, les règles de transfert applicables et la politique de stockage retenue par l’équipe. Cet article ne remplace pas l’avis du comité d’éthique ou du service juridique.

Commencez par un échantillon désensibilisé. Retirez les noms, voix reconnaissables, coordonnées, identifiants indirects et métadonnées inutiles. Conservez l’original dans un emplacement contrôlé et en lecture seule. Le fichier de test doit néanmoins reproduire la structure du travail réel : documents, codes, mémos, groupes et exports.

Les fichiers audio et vidéo demandent une vérification supplémentaire. Il faut distinguer :

• les fichiers intégrés au projet ;
• les fichiers conservés à l’extérieur ;
• les liens vers un stockage institutionnel ;
• les chemins locaux propres à un appareil.

Un lien qui fonctionne sur Windows peut échouer sur Mac si le chemin dépend d’un dossier local. Après changement d’appareil, vérifiez l’ouverture du média, la lecture, la synchronisation du lien et la possibilité d’exporter les résultats sans déplacer l’original.

Si le stockage en ligne n’est pas autorisé ou si les médias externes ne sont pas récupérables de manière stable, conservez le projet de bureau local et utilisez une procédure de transfert contrôlée. Dans ce cas, Project Cloud ne doit pas devenir le seul emplacement de conservation.

[ SECTION_07 ] La checklist de validation permet de décider avant les données réelles

Cette liste peut être exécutée par un responsable de recherche ou par le support informatique. Une case non validée doit produire une décision : corriger, changer de voie ou arrêter le déploiement.

• [ ] Le rôle de chaque membre et du propriétaire du projet maître est écrit.
• [ ] Une copie originale, désensibilisée si nécessaire, est conservée en lecture seule.
• [ ] Chaque appareil utilisé a été contrôlé selon les prérequis officiels.
• [ ] La licence et son activation ont été vérifiées sur l’appareil prévu ; la documentation officielle d’activation sert de référence.
• [ ] La reprise individuelle entre Mac et Windows a été testée avec téléchargement puis téléversement.
• [ ] L’équipe sait qu’aucun travail simultané ne doit être effectué sur le même projet Project Cloud.
• [ ] Une copie de travail a été distribuée depuis un projet maître clairement identifié.
• [ ] Le retour d’un codeur a été fusionné sans document en double.
• [ ] Les identités des codeurs et les conflits sont lisibles après fusion.
• [ ] Un transfert entre ATLAS.ti Web et la version de bureau a été testé sans supposer une visibilité réciproque.
• [ ] Les médias intégrés ou externes restent accessibles après changement d’appareil.
• [ ] Les exports attendus ont été ouverts sur la plateforme utilisée pour la rédaction.
• [ ] Les fichiers temporaires et les téléchargements ont été supprimés après l’essai.
• [ ] La procédure d’incident indique quoi faire lorsqu’une version locale et une version distante divergent.

Si les cases relatives à la version maître, à l’identité des codeurs ou au retour des médias restent vides, le protocole n’est pas prêt pour des données de participants.

[ SECTION_08 ] Un Mac distant sert à valider la version bureau sans acheter immédiatement

Comment vérifier la version Mac d’ATLAS.ti quand le laboratoire n’a pas de Mac ?

Le test doit porter sur une copie désensibilisée, jamais sur les entretiens originaux. Préparez un petit projet représentatif, puis exécutez les opérations dans cet ordre :

1. Ouvrez une session Mac distante et confirmez que l’application démarre.
2. Vérifiez l’activation de la licence avec le compte prévu pour l’étude.
3. Téléchargez ou transférez le projet test.
4. Ouvrez plusieurs documents, codes, mémos et relations utiles.
5. Réalisez une opération d’analyse réellement nécessaire au protocole.
6. Exportez un résultat dans le format utilisé par l’équipe.
7. Récupérez le fichier exporté sur l’environnement institutionnel.
8. Fermez l’application, supprimez les copies temporaires et contrôlez la fin de session.

Cette procédure mesure trois choses distinctes : la compatibilité de l’application, l’acceptabilité de la commande à distance et la capacité à ramener un résultat exploitable. Elle ne permet pas de conclure qu’un Mac distant convient automatiquement à de longues sessions d’analyse ou à des médias volumineux.

Une équipe universitaire peut commencer par examiner les environnements Mac disponibles avec NOVAKVM, puis retenir un nœud adapté à sa politique de connexion. Pour une validation ciblée, la page de commande d’un Mac mini M4 distant peut servir de point de départ. La licence ATLAS.ti, le droit d’usage des données et la politique de l’établissement restent toutefois à vérifier séparément.

Le score de décision peut être formulé ainsi :

• Project Cloud : 4/5 pour une personne alternant entre appareils ; 1/5 pour la coédition simultanée.
• ATLAS.ti Web : 4/5 lorsque le codage partagé dans le navigateur est prioritaire ; score à réduire si une fonction de bureau est indispensable.
• Fusion de projets : 4/5 pour une équipe asynchrone structurée ; score faible sans projet maître.
• Mac distant : 3/5 comme environnement de validation ou d’accès temporaire ; score à ajuster selon la connexion, la licence et la sensibilité des données.

Ces notes ne sont pas des mesures de performance. Elles traduisent uniquement l’adéquation entre une voie et un scénario précis.

[ SECTION_09 ] Le choix final dépend du protocole, pas du seul système d’exploitation

Pour une reprise individuelle entre Mac et Windows, Project Cloud peut être retenu si la règle « une personne, une session d’édition » est appliquée. Pour une équipe qui code en parallèle, ATLAS.ti Web doit être testé en premier. Pour l’analyse de bureau, la fusion et l’accord entre codeurs, la méthode la plus contrôlable reste un projet maître, des copies distribuées et une fusion vérifiée. Pour un laboratoire sans Mac, le Mac distant est un moyen de valider la version bureau avant une décision d’achat ou de déploiement.

Le poste actuel peut sembler plus simple, mais un parc limité à Windows ou Linux ne donne pas accès à la version Mac de bureau, oblige parfois à improviser des transferts et ne permet pas de valider l’expérience réelle avant le lancement de l’étude. Une machine virtuelle ou un poste partagé ajoute souvent des contraintes de licence, de maintenance et de disponibilité. Dans ces conditions, louer temporairement un Mac auprès de NOVAKVM peut être plus rationnel pour un essai contrôlé : le groupe utilise un environnement macOS réel, exécute le protocole sur un projet désensibilisé, puis décide avec des preuves s’il faut acheter un Mac, retenir ATLAS.ti Web ou maintenir une chaîne de fusion.

La bonne décision n’est donc pas de déplacer immédiatement les données sensibles. Elle consiste à valider le flux complet — ouverture, codage, fusion, export et nettoyage — sur une copie sans information identifiable, puis à documenter la voie retenue par le responsable de l’étude.