Résumé

  • Les deux parties utilisent leurs sièges payants dans un dossier connecté. Après déconnexion, le dossier reste chez l'hôte et l'équipe externe perd l'accès aux fichiers.
  • Envoyer une copie laisse les commentaires, l'historique des versions et les branches avec les originaux. Le prochain prestataire peut recevoir les écrans sans toute l'histoire de leur conception.
  • Une bibliothèque absente du transfert cesse d'alimenter les fichiers transférés. Transférer la bibliothèque elle-même prive de mises à jour les fichiers restés chez l'expéditeur.

Le dernier rendez-vous avec une agence peut se terminer sur une phrase rassurante : les fichiers sont livrés. Le premier rendez-vous avec la suivante commence parfois par une question moins confortable : où modifie-t-on le composant d'origine ?

Imaginons un client qui change de prestataire après une mission réalisée dans Figma. Les deux entreprises ont participé aux revues, commenté les variantes et payé chacune leurs propres sièges. Cette égalité visible laisse facilement supposer une égalité de maîtrise. Or le produit se souvient d'un choix effectué bien avant la dernière facture : qui a créé le dossier connecté et invité l'autre partie ?

Cette partie est l'hôte, ou host. L'autre est l'équipe externe. Ce détail d'installation devient une donnée commerciale au moment de se séparer.

Deux sorties, une seule garde des originaux

Le guide des dossiers connectés exige un abonnement payant de chaque côté et l'approbation des administrateurs des deux parties. Pour modifier un fichier, il faut également le siège approprié et le droit de le modifier. Le paiement du siège et la permission sur le fichier règlent deux questions distinctes.

L'hôte contrôle notamment les paramètres de sécurité et de confidentialité, les fonctions disponibles et les bibliothèques proposées à l'équipe externe. Les deux côtés peuvent créer ou importer des fichiers dans le dossier. Seuls les membres du côté hôte peuvent les en sortir.

Un administrateur de l'une ou l'autre partie peut déconnecter le dossier. Mais après cette opération, le dossier reste chez l'hôte et l'équipe externe perd l'accès à tous ses fichiers. L'hôte peut ne rien faire, envoyer une copie, puis éventuellement transférer le dossier.

Le droit de mettre fin à la collaboration est donc partagé. La position après la rupture ne l'est pas. Les deux partenaires peuvent quitter la réunion ; un seul se retrouve spontanément avec l'armoire.

Ce résultat rend le choix initial de l'hôte trop important pour le laisser à la personne qui ouvre l'écran de configuration en premier. Un projet destiné à vivre durablement chez le client et un service de conception maintenu par l'agence n'appellent pas forcément la même organisation. La question appartient au début de la mission, quand les deux parties peuvent encore définir tranquillement ce qu'elles veulent conserver à la fin.

La copie emporte le résultat, pas toute la conversation

La documentation de transfert distingue l'envoi d'une copie du transfert du dossier. Avec la copie, commentaires, historique des versions et branches restent avec les originaux.

Pour une nouvelle équipe, ce sont parfois les raisons du dessin qui manquent. Pourquoi cette disposition a-t-elle été abandonnée ? Pourquoi ce cas particulier subsiste-t-il ? Si la réponse vivait dans une discussion ou une version antérieure, le nouveau prestataire peut devoir refaire l'enquête. Le nombre de fichiers livrés n'a pas changé. Le travail nécessaire pour les comprendre, si.

Un transfert de dossier peut être reçu par un abonnement Professional, Organization ou Enterprise ; le transfert d'une équipe entière demande Organization ou Enterprise. Les liens des fichiers et prototypes restent utilisables, tandis que dossiers et équipes obtiennent de nouveaux liens. Ces différences méritent des lignes distinctes dans une définition de livraison.

Le guide de collaboration avec les clients décrit aussi l'export local puis l'import dans un autre compte. Les mises à jour provenant de la bibliothèque de l'équipe d'origine ne suivent pas ce chemin. Un téléchargement réussi atteste l'arrivée d'un fichier, pas l'arrivée de son avenir.

Une bibliothèque commune ne se livre pas comme une affiche

Une bibliothèque Figma réunit composants, styles et variables dans un fichier source réutilisable ailleurs. Pour une agence, cette réserve de boutons, de couleurs et de règles visuelles représente une économie de travail. Elle peut servir plusieurs projets.

Au transfert, cette économie commune impose un choix. Si la bibliothèque manque dans le lot, les composants gardent leur dernier état et ne reçoivent plus ses mises à jour. Si le fichier de bibliothèque publié part lui-même, les fichiers laissés dans l'équipe ou l'organisation expéditrice cessent de recevoir ses mises à jour.

Livrer un client en emportant l'atelier qui en sert d'autres serait une curieuse forme de générosité. À l'inverse, livrer uniquement les écrans tout en laissant au client l'idée qu'il pourra entretenir seul toute la conception prépare une autre facture, plus tard.

Il faut distinguer les éléments propres au client, les éléments communs de l'agence et le service futur de maintenance. Le dossier connecté ne résout pas cette répartition à leur place. Lorsque l'hôte donne accès à une bibliothèque, les membres obtiennent un accès en lecture à son fichier source. Employer un composant dans une page ne donne donc pas automatiquement le pouvoir de modifier son origine.

Le vrai reçu est la prochaine modification

La fonction de remplacement de bibliothèques permet de raccorder un fichier à des ressources d'une autre bibliothèque publiée. Figma cherche des noms correspondants. Les éléments sans correspondance restent liés à la bibliothèque d'origine. Une ressemblance visuelle ou un nouveau nom ne suffisent pas.

Un compte rendu de migration doit donc dire ce qui a changé de source et ce qui est resté derrière. Même un nom identique mérite une vérification de sens. Sinon, un fichier peut avoir l'air homogène tout en dépendant de deux chemins de maintenance différents. La capture d'écran est un excellent portrait ; elle fait un médiocre inventaire des dépendances.

La revue des mises à jour revient aux personnes ayant le droit de modifier le fichier. Une réception sérieuse peut suivre un changement représentatif : le publier depuis la source convenue, puis le revoir et l'accepter dans le fichier du destinataire avec ses droits réels. Le résultat prouve davantage que l'ouverture d'un fichier ancien.

Pour chiffrer une sortie particulière, il faut connaître l'hôte, les dépendances et le périmètre de livraison convenu. Le principe commercial, lui, est déjà visible : un bon transfert donne au prochain responsable la capacité de travailler demain. Les chaises peuvent figurer sur deux factures. La clé mérite une décision commune.