Pendant longtemps, le travail du designer avait une matérialité familière : un fichier Illustrator, Photoshop ou InDesign, soigneusement rangé dans un dossier, accompagné de ses images, de ses polices et de quelques versions numérotées. Les pratiques collaboratives, les design systems, le cloud et désormais les outils génératifs ont progressivement déplacé cette organisation. Le projet graphique existe toujours, mais sa « source » devient plus difficile à désigner.
Du fichier maître au projet permanent
Il y avait quelque chose de rassurant dans l’idée du fichier source. Derrière une affiche imprimée, un logo ou une maquette éditoriale existait un document qui contenait le travail dans sa forme modifiable. On pouvait l’ouvrir, parcourir ses calques, retrouver les tracés, modifier un texte ou examiner la construction d’une composition. Même lorsque les dossiers accumulaient les fameux FINAL, FINAL_2 et FINAL_VRAIMENT, la logique restait compréhensible : quelque part se trouvait une version considérée comme la référence.
Cette organisation correspondait aussi à une certaine manière de produire. Un designer travaillait sur son poste, enregistrait son fichier, l’envoyait éventuellement à un collègue ou au client, puis archivait l’ensemble à la fin du projet. Le document possédait une frontière relativement nette. Il pouvait être copié sur un disque dur, transmis ou conservé plusieurs années.
Le travail contemporain brouille cette frontière. Une interface conçue aujourd’hui dans Figma peut être modifiée simultanément par plusieurs personnes, dépendre d’une bibliothèque de composants située ailleurs, intégrer des variables partagées et évoluer à travers un historique de versions. Les branches permettent même d’expérimenter séparément avant de réintégrer les modifications au fichier principal. Figma enregistre parallèlement des points de contrôle dans l’historique et associe les évolutions des bibliothèques à cet ensemble. Le projet ressemble moins à un document figé qu’à un environnement en mouvement.
La fin de la « dernière version »
Le changement peut sembler essentiellement technique. Il modifie pourtant une notion profondément ancrée dans les métiers graphiques : celle de la version finale.
Dans un environnement collaboratif, une maquette peut continuer à évoluer après sa validation initiale. Un composant change dans une bibliothèque et plusieurs écrans héritent de la modification. Une équipe marketing intervient sur les contenus pendant que les développeurs consultent les spécifications. Un designer corrige un élément déjà utilisé ailleurs. Chaque état du projet reste accessible dans un historique, mais aucun ne possède nécessairement le statut définitif qu’avait autrefois le fichier envoyé à l’imprimeur.
Adobe suit d’ailleurs une évolution comparable avec ses documents en ligne. Photoshop, Illustrator ou InDesign permettent désormais de conserver des documents dans Creative Cloud, de les retrouver sur plusieurs appareils, de sauvegarder automatiquement les modifications et de revenir à des versions précédentes. Le logiciel de bureau demeure, mais le document s’inscrit lui aussi dans une continuité plutôt que dans une succession de fichiers indépendants.
La célèbre nomenclature artisanale des dossiers — V1, V2, V3, V3-bis, final — laisse ainsi progressivement place à une chronologie intégrée au logiciel. Le designer conserve moins de fichiers distincts tout en produisant davantage d’états successifs.
Quand le fichier dépend de ce qui se trouve ailleurs
Cette transformation devient particulièrement visible avec les design systems. Une interface peut contenir des centaines d’instances de composants dont la définition originale se situe dans une bibliothèque extérieure au document. Une couleur n’existe plus nécessairement comme une simple valeur hexadécimale appliquée à un objet : elle peut être liée à une variable globale, elle-même utilisée dans de multiples produits, thèmes ou états.
Ouvrir le fichier ne suffit donc plus toujours à comprendre entièrement le projet. Une partie de sa logique réside dans les relations qu’il entretient avec d’autres ressources.
Cette logique dépasse largement l’UI. Les identités visuelles contemporaines comprennent fréquemment des bibliothèques de composants, des templates en ligne, des éléments animés, des systèmes typographiques variables, des contenus pour les réseaux sociaux et des règles destinées à différents outils de publication. Le livrable devient un écosystème. À mesure que les identités gagnent en flexibilité, leur source se distribue entre davantage de fichiers, de plateformes et de personnes.
Le changement touche également la responsabilité du designer. Livrer un projet signifiait autrefois remettre un ensemble identifiable de documents. La transmission d’un système implique désormais de transmettre également des règles, des accès, des dépendances et une manière de le faire évoluer.
L’IA ajoute une nouvelle couche au problème
Les outils génératifs rendent la question encore plus difficile à résoudre. Où se situe la source d’une image générée puis retouchée ? Dans le fichier Photoshop final ? Dans le prompt initial ? Dans les images de référence ? Dans les générations rejetées qui ont permis d’affiner la direction ? Dans le modèle utilisé au moment de la création ?
La chaîne de fabrication peut devenir étonnamment longue. Un designer génère plusieurs pistes, récupère une image, la transforme dans Photoshop, l’étend avec un autre outil, reprend certaines parties manuellement puis l’intègre dans une composition développée ailleurs. Le document final conserve le résultat, mais très peu de traces du chemin qui y a conduit.
Cette situation donne une importance nouvelle à la documentation. Conserver un prompt, une capture d’écran, une référence de modèle ou une étape intermédiaire peut devenir aussi pertinent que conserver les calques d’un fichier. La mémoire du processus se trouve alors dispersée dans plusieurs outils dont les historiques n’ont pas été conçus pour former ensemble une archive cohérente.
La question du fichier source rejoint ainsi celle, plus ancienne, de la traçabilité du processus créatif. Simplement, le nombre d’intermédiaires a considérablement augmenté.
Archiver un travail qui vit dans le cloud
Le paradoxe apparaît au moment où le projet doit être conservé. Les outils actuels enregistrent énormément de données : versions, commentaires, modifications, composants, branches, bibliothèques. Ils produisent parfois une mémoire plus détaillée du travail qu’un fichier traditionnel. Mais cette mémoire dépend d’un environnement précis.
Figma indique par exemple que l’accès à l’historique complet varie selon les formules utilisées ; les équipes Starter n’accèdent qu’aux trente derniers jours, tandis que d’autres offres donnent accès à un historique étendu. La conservation d’un processus créatif peut donc dépendre du maintien d’un compte, d’une organisation et de droits d’accès.
Cette dépendance pose une question rarement visible pendant la production : que restera-t-il du projet dans dix ou vingt ans ?
Les archives du design ont longtemps pu recueillir esquisses, maquettes, affiches, films, fichiers numériques et documents préparatoires. La conservation d’un projet conçu dans un environnement SaaS suppose désormais de préserver des relations entre des éléments plutôt qu’un simple objet numérique. Une bibliothèque peut avoir disparu, un plugin ne plus fonctionner, un service avoir changé de modèle économique ou un format ne plus reproduire exactement le comportement d’origine.
Le problème rappelle celui rencontré depuis longtemps avec les logiciels propriétaires et les formats devenus obsolètes, mais le cloud en augmente l’échelle. Le document lui-même peut rester accessible tandis qu’une partie de son fonctionnement a disparu.
Ce que le fichier racontait du travail
Il existe enfin une dimension plus culturelle. Observer un fichier de travail permet de comprendre une manière de penser. Les calques abandonnés, les essais typographiques laissés hors du plan de travail, les objets masqués ou les variantes non retenues racontent autant le projet que son résultat final. Les archives des designers tirent précisément une partie de leur richesse de ces traces intermédiaires.
Dans un environnement où chaque action peut être automatiquement sauvegardée, cette mémoire devrait théoriquement devenir immense. Pourtant, elle risque aussi de devenir moins lisible. Des centaines d’états successifs ne constituent pas nécessairement une histoire. Sans sélection, commentaire ou contextualisation, l’abondance d’informations peut rendre le processus plus opaque plutôt que plus accessible.
La question touche directement au rôle du designer dans la constitution de ses propres archives. Quels états méritent d’être conservés ? Quels éléments permettent de comprendre une décision ? Faut-il enregistrer le système complet ou seulement ses résultats les plus significatifs ? La conservation devient à son tour un geste éditorial.
Une source devenue multiple
Le fichier source n’a finalement pas disparu. Il s’est fragmenté.
Il peut encore prendre la forme familière d’un .ai, d’un .psd ou d’un .indd, mais il peut aussi être réparti entre un espace Figma, une bibliothèque partagée, un historique de versions, un dossier cloud, des composants, des prompts, des références et plusieurs services connectés. Sa définition repose de moins en moins sur un format et davantage sur l’ensemble des éléments nécessaires pour comprendre, modifier et poursuivre un projet.
Cette évolution accompagne celle du métier lui-même. Le designer produit moins souvent un objet isolé et intervient davantage sur des systèmes capables d’évoluer, d’être repris et transformés par d’autres. La source devient alors collective, mouvante et parfois difficile à circonscrire.
Reste une question que les outils ne pourront pas résoudre seuls : comment conserver la mémoire d’un projet lorsque celui-ci n’a plus vraiment de début, de fin, ni même de fichier unique ?
