Skip to main content
Il est important de réaliser une sauvegarde cohérente avant chaque migration de version majeure, afin de pouvoir revenir en arrière si nécessaire.

Migrer depuis Overleaf Community

Cas 01 : depuis l’Overleaf Toolkit

Si vous utilisez l’Overleaf Toolkit officiel pour Overleaf Community, il vous suffit d’ajouter un fichier nommé docker-compose.override.yml, avec le contenu suivant ou un contenu similaire, dans le répertoire overleaf-toolkit/config :
docker-compose.override.yml
Pour démarrer votre instance, exécutez :
Et voilà, tout est prêt ! Vous pouvez ensuite vérifier que votre instance Ayakaleaf fonctionne correctement et que vous pouvez accéder à l’interface web. Une fois que tout fonctionne, poursuivez avec les étapes de configuration ci-dessous pour activer les fonctionnalités avancées telles que :

Cas 02 : depuis un fichier Docker Compose

Si vous utilisez un fichier docker-compose.yml autonome, migrez-le d’abord vers l’Overleaf Toolkit. Le Toolkit simplifie l’installation sur site, les mises à niveau et la maintenance. Suivez le guide docker-compose.yml-to-toolkit-migration.md pour convertir votre déploiement existant. Conservez votre configuration actuelle et les chemins de vos volumes de données pendant cette migration. Une fois le déploiement Toolkit opérationnel, suivez #from-overleaf-toolkit pour remplacer son image par Ayakaleaf Pro. Démarrez l’instance avec bin/up, puis vérifiez que vous pouvez accéder à l’interface web.

Migrer depuis Overleaf Server Pro

Si vous exploitez actuellement une instance sous licence commerciale d’Overleaf Server Pro et souhaitez migrer vers Ayakaleaf Pro, sachez que la migration peut demander un travail supplémentaire, car certains formats de données (templates) peuvent ne pas être entièrement compatibles. Nous serons toutefois ravis de vous aider. Veuillez ouvrir une issue ou nous contacter à l’adresse ayaka-notes@outlook.com, et nous vous aiderons gratuitement à migrer vers Ayakaleaf Pro.

Migrer depuis Overleaf CEP

Les utilisateurs nous demandent souvent s’ils peuvent migrer d’Overleaf CEP vers Ayakaleaf Pro. Dans la plupart des cas, Overleaf CEP et Ayakaleaf Pro offrent des fonctionnalités globalement équivalentes et restent compatibles au niveau des données à partir de la version 6.2.0. Les deux projets peuvent publier des fonctionnalités à des moments différents ; par exemple, nous pouvons reprendre (cherry-pick) une fonctionnalité d’Overleaf CEP, et inversement. Bien que nos implémentations d’une même fonctionnalité puissent légèrement différer, il n’y a généralement aucune raison impérieuse de migrer. Si vous souhaitez tout de même migrer vers Ayakaleaf Pro ou l’essayer, reportez-vous à : #case-01-from-overleaf-toolkit. La procédure de migration est la même.

Migrer depuis Overleaf SaaS

Malheureusement, migrer de la plateforme SaaS d’Overleaf vers une instance Ayakaleaf Pro auto-hébergée peut s’avérer nettement plus difficile. À l’heure actuelle, la seule méthode généralement disponible consiste à télécharger chaque projet sous forme d’archive ZIP, puis à l’importer dans votre instance Ayakaleaf Pro auto-hébergée. Seuls les fichiers actuels du projet sont ainsi transférés, ce qui signifie que vous perdrez :
  • Tout l’historique du projet et les révisions précédentes
  • Tous les commentaires et les modifications suivies
  • Toutes les métadonnées Git et l’historique des commits
  • Tous les liens et paramètres de synchronisation GitHub
  • Tous les liens entre les fichiers BibTeX et les plateformes tierces de gestion de références

Migrer depuis un fork tiers d’Overleaf

Ayakaleaf Pro peut ne pas prendre en charge les fonctionnalités propres à un fork tiers d’Overleaf. Dès lors qu’un fork s’écarte significativement du code d’Overleaf en amont — ou introduit des modifications sans maintenir la compatibilité avec l’amont —, l’intégration des versions ultérieures d’Overleaf peut devenir extrêmement difficile. Vous pouvez tout de même essayer la méthode de migration décrite ci-dessus, mais la compatibilité n’est pas garantie, et nous pourrions ne pas être en mesure de fournir une assistance ou un support technique pour les migrations depuis des forks non pris en charge.
Dernière modification le 4 octobre 2026