Collaboration After Effects : travailler à plusieurs sans conflits de projet

This article is currently available in French only. The page chrome is translated, the article body is not — yet.

Comprendre pourquoi AE pose problème en contexte multi-utilisateurs

Un fichier .aep stocke l'intégralité du projet dans une structure propriétaire : compositions, métadonnées, chemins de médias, expressions, paramètres de rendu. Quand deux personnes travaillent sur des copies distinctes et qu'elles tentent de les fusionner, il n'existe pas de système de merge natif équivalent à Git pour le code. Le résultat est systématiquement une opération manuelle risquée.

Le problème se double d'une question de chemins de fichiers. Si chaque poste a un montage de serveur différent — /Volumes/NAS sur Mac, Z:\ sur Windows — les liaisons vers les médias se cassent dès qu'on ouvre le projet sur une autre machine. Ce point est souvent négligé jusqu'au premier incident de production, quand un animateur en remote ouvre le fichier et voit 200 footages hors ligne.

Enfin, les expressions JavaScript qui référencent des couches par leur nom ou leur index sont particulièrement fragiles dans un contexte collaboratif. Dès qu'un collègue renomme une couche ou en déplace une dans la pile, des expressions sur d'autres compositions peuvent silencieusement casser sans déclencher d'alerte visible dans le panneau de rendu.

Découper le projet en fichiers AEP indépendants dès le départ

La méthode la plus robuste consiste à ne jamais travailler dans un fichier unique. On divise le projet en autant de fichiers .aep qu'il y a de modules distincts : un fichier par séquence, par chapitre, par variante de langue ou par bloc graphique réutilisable. Chaque motion designer est propriétaire exclusif de son ou ses fichiers pendant une phase de production donnée.

La composition master — celle qui assemble l'ensemble pour le rendu final — importe les pré-comps depuis les fichiers satellites via la fonction Fichier > Importer > Fichier ou en utilisant des Dynamic Links vers Premiere Pro si le workflow le permet. Cette composition master reste idéalement la responsabilité d'un seul membre de l'équipe, généralement le directeur technique ou le lead animator.

Concrètement, pour une série de 10 épisodes d'animation de 90 secondes chacun, on peut avoir : un fichier kit_graphique.aep partagé en lecture seule qui contient tous les éléments de brand (logos animés, typographies, transitions génériques), puis un fichier ep01.aep, ep02.aep, etc., chacun assigné à un animateur. Le kit graphique est importé dans chaque épisode mais jamais modifié directement par les animateurs — toute demande de modification passe par le responsable du kit.

Mettre en place une convention de nommage non négociable

Dans un projet collaboratif, l'absence de convention de nommage génère des conflits humains avant même de générer des conflits techniques. Quand chaque animateur nomme ses compositions à sa façon — COMP_FINALE, comp test ok 2, version PROPRE — l'assemblage final devient un cauchemar d'identification.

Une convention minimale efficace pour les compositions : [NUM_SEQUENCE]_[NOM_SCENE]_[VERSION]. Par exemple : 03_INTRO_PRODUIT_v04. Pour les couches : une préfixation par type — [TXT] pour les calques texte, [SHP] pour les shapes, [VID] pour les footages vidéo, [NULL] pour les nulls de contrôle. Ces préfixes permettent de scanner visuellement une timeline de 60 couches sans lire chaque nom en entier.

Pour les fichiers de projet eux-mêmes, le versionning manuel reste la norme dans beaucoup de studios : ep03_v01.aep, ep03_v02.aep, jamais d'écrasement. Certaines équipes ajoutent les initiales de l'animateur — ep03_v02_ML.aep — pour identifier immédiatement qui a produit quelle version en cas de question. Ce n'est pas la solution la plus sophistiquée, mais elle est universellement lisible, sans dépendance logicielle et sans courbe d'apprentissage.

Utiliser un serveur partagé avec une structure de dossiers standardisée

L'organisation des médias sur le serveur partagé est aussi critique que l'organisation des fichiers AEP. Une structure qui a fait ses preuves en production :

/NOM_PROJET/
_ASSETS/ (médias sources bruts, jamais modifiés)
_EXPORTS/ (rendus intermédiaires et livrables)
_AEP/ (fichiers de projet After Effects)
_DOCS/ (briefs, scripts, notes de prod)
_PRE_COMPS_EXPORTS/ (pré-comps rendues en ProRes ou PNG sequences pour assemblage)

Le dossier _ASSETS est en lecture seule pour tout le monde sauf l'asset manager ou le chef de projet. Quand un animateur a besoin de modifier un visuel source, il en crée une copie dans un sous-dossier /ASSETS_MODIFIED/ avec sa modification, sans jamais toucher à l'original. Cette règle évite les situations où une modification d'asset en amont casse silencieusement le travail de trois autres animateurs qui utilisaient le même fichier.

La clé pour que les liaisons AEP fonctionnent sur tous les postes est de monter le serveur toujours au même point de montage. Sur Mac, on utilise souvent un script de connexion automatique qui monte le NAS systématiquement sous /Volumes/STUDIO_NAS quel que soit le poste. Sur Windows, on mappe toujours la même lettre de lecteur. Dès ce point de montage standardisé en place, les chemins dans les fichiers AEP restent valides d'une machine à l'autre.

Gérer les versions avec Git LFS ou un système de versioning adapté

Git est l'outil de versioning standard pour le code, mais les fichiers binaires volumineux comme les .aep sont mal gérés par Git classique. Git LFS (Large File Storage) résout ce problème en stockant les binaires sur un serveur séparé tout en conservant les pointeurs dans le dépôt Git. C'est une approche utilisée par des équipes techniques avancées, mais elle nécessite que tous les membres sachent utiliser Git, ce qui est rarement le cas dans une équipe de motion designers pure.

Pour les équipes qui ne veulent pas de Git, des alternatives existent. Resilio Sync ou Syncthing permettent de synchroniser des dossiers entre machines en peer-to-peer avec un historique de versions configurable. Certains studios utilisent Dropbox Business avec la fonctionnalité de versioning étendu (180 jours d'historique) : quand un fichier est écrasé par erreur, on peut restaurer n'importe quelle version antérieure depuis l'interface web.

Frame.io, souvent utilisé pour la review client, propose aussi des fonctionnalités d'organisation de versions de fichiers qui peuvent servir de référentiel de livrables intermédiaires. Ce n'est pas du versioning technique au sens strict, mais ça permet de retrouver la version rendue de vendredi dernier quand le client demande de revenir en arrière après avoir approuvé une direction.

Organiser les phases de production pour éviter les conflits humains

Les conflits de fichiers les plus courants en studio ne viennent pas d'un bug technique, mais d'un manque de synchronisation humaine. Deux animateurs qui travaillent simultanément sur des éléments qui se chevauchent — l'un anime une scène pendant que l'autre modifie le kit graphique dont dépend cette scène — génèrent des incohérences qui prennent des heures à diagnostiquer.

La solution passe par un planning de production explicite avec des phases clairement séparées. Phase 1 : le responsable technique et le directeur artistique construisent le kit graphique et la structure master, les autres attendent. Phase 2 : chaque animateur travaille sur ses séquences assignées, le kit graphique est gelé sauf urgence. Phase 3 : assemblage et révisions globales, un seul responsable touche aux fichiers d'assemblage pendant que les autres répondent aux notes de révision sur leurs séquences respectives.

Un outil simple comme un tableau Notion ou même un Google Sheet partagé avec les noms de fichiers, les responsables assignés et les statuts (En cours / En révision / Validé / Rendu) permet à toute l'équipe de voir en un coup d'œil qui travaille sur quoi. Ce n'est pas spectaculaire, mais c'est ce qui évite l'appel à 18h30 : 'Attends, j'ai écrasé ta version ?'

ConclusionConclusion

Travailler à plusieurs sur After Effects demande une discipline que l'outil lui-même n'impose pas. La combinaison d'une architecture de fichiers modulaire, de conventions de nommage respectées par tous, d'un serveur correctement structuré et d'un planning de production qui séquence clairement les phases de travail permet de produire en équipe sans les drames habituels. Les outils de versioning et de synchronisation viennent en complément, mais ne remplacent jamais une bonne organisation humaine. Le vrai gain de temps dans un studio multi-animateurs ne vient pas du dernier plugin à la mode, mais de décisions d'architecture prises le premier jour du projet et respectées jusqu'à la livraison.