Il n'y a rien
à migrer.
- 01Rien ne quitte le repositoryVous n’exportez, ne convertissez et ne téléversez rien. Le markdown reste exactement où il est, dans sa branch, géré par git et relu comme votre équipe le relit déjà.
- 02Vous connectez, ce qui prend environ trois minutesUn accès en lecture seule aux repositories que vous choisissez, une branch prise dans la vraie liste, et la racine de documentation trouvée pour vous. Il n’y a pas d’étape de configuration, car il n’y a pas de configuration.
- 03Vous gardez votre ancien outil aussi longtemps que vous le souhaitezLa connexion ne change rien à votre site existant. Faites tourner les deux, décidez avec votre équipe, et arrêtez l’un d’eux — ou aucun. Il n’y a ni bascule ni période pendant laquelle la documentation est indisponible.
Ce qui suit, et ce qui ne suit pas
La seconde liste est celle qui mérite d'être lue. Tout ce qui s'y trouve est un non-objectif délibéré plutôt qu'une lacune.
Ce qui vous suit
- Chaque fichier markdown
- Lus tels qu’ils sont écrits, y compris ceux que la configuration de votre ancien outil n’a jamais listés.
- Votre structure de dossiers
- Elle devient la navigation telle quelle — c’est tout le produit.
- Titres, tableaux, blocs de code, Mermaid
- CommonMark et GFM, correctement rendus.
- Les titres du front matter
- Utilisés quand ils existent ; sinon le premier titre, puis le nom de fichier.
- Les liens relatifs entre documents
- Résolus, et signalés comme constat de santé quand l’un d’eux ne mène nulle part.
- Votre historique git
- Intact. Nous n’écrivons jamais dans votre repository.
Ce qui ne suit pas
- Une navigation ordonnée à la main
- L’ordre est déduit : README d’abord, puis les préfixes numériques, puis l’ordre alphabétique des titres. Si le chapitre trois doit suivre le chapitre deux pour une raison qu’aucun nom de fichier ne traduit, cette intention ne survit pas.
- Les composants MDX personnalisés
- Les fichiers `.mdx` sont indexés et lus comme du texte ; aucun JSX n’est évalué. Un fichier fait surtout de composants se lira comme presque vide.
- Votre thème et votre CSS personnalisé
- Le reader est une seule surface en deux thèmes. Un site public reprend votre logo, votre favicon et vos couleurs, pas votre propre CSS.
- Vos URL publiques et leur référencement
- Un site public vit à l’adresse docsflowy.site de votre équipe : les adresses que votre site actuel a gagnées dans les moteurs de recherche ne le suivent pas. Si ces URL comptent, laissez ce site où il est.
- Les règles de redirection et les chemins personnalisés
- Les chemins viennent du repository. Il n’y a pas de table de redirection.
D'où arrivent les équipes
Depuis MkDocs, Docusaurus ou GitBook
Votre markdown est déjà dans le repository et déjà rangé en dossiers. Connectez-le et comparez l’arborescence que nous construisons à la navigation que vous entreteniez à la main. Si la nôtre est fausse, c’est un bug de découverte qui mérite d’être signalé.
Depuis Mintlify
Ses pages sont construites autour de ses propres composants et de son fichier de navigation, elles ne passent donc pas telles quelles. Si votre site pour les clients fonctionne, gardez-le, et indiquez-nous les repositories internes qui n’allaient jamais y figurer. Si vous voulez des pages publiques écrites avec le travail, le manuel les publie sous forme de versions nommées.
Depuis un wiki
C’est le seul cas qui demande un vrai travail : le contenu doit d’abord devenir du markdown dans un repository. Une fois là, la connexion prend les mêmes trois minutes que pour le reste.
En partant de rien
Le cas courant. Les documents existent, dans six repositories, et personne ne leur a jamais associé d’outil de documentation, car chacun exigeait d’abord un fichier de configuration.
Se déconnecter tient en un clic, et ne laisse rien derrière
La propriété qui rend l'arrivée peu coûteuse rend le départ peu coûteux, et un produit facile à quitter est un produit qui doit mériter qu'on y reste.
Déconnectez un repository et nous cessons de le lire. Révoquez la GitHub App depuis les paramètres de GitHub et nous ne pouvons plus le lire, que nous arrêtions ou non — l’interrupteur est de votre côté, pas du nôtre. Votre markdown est là où il a toujours été, dans la même branch, avec un historique dans lequel nous n’avons jamais écrit.
Ce que vous perdriez, c’est la couche que nous avons ajoutée par-dessus : les états de relecture et d’implémentation, les notes, les accusés de lecture, les constats de santé et les artifacts déposés par un agent. Ils sont chez nous parce qu’ils n’ont jamais existé dans votre repository — et si cela compte pour vous, mieux vaut poser la question avant de commencer qu’après.
Pointez-le vers un repository et laissez tout le reste tourner.
Il n’y a pas de bascule à planifier, donc rien à défaire si vous changez d’avis.
Commencer gratuitement